From owner-atom-syntax@mail.imc.org Fri Apr 1 05:24:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09381 for ; Fri, 1 Apr 2005 05:24:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31AFEs3002811; Fri, 1 Apr 2005 02:15:14 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j31AFEbG002810; Fri, 1 Apr 2005 02:15:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31AF7Pc002753 for ; Fri, 1 Apr 2005 02:15:07 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 52111 invoked by uid 17064); 1 Apr 2005 10:15:06 -0000 Received: from unknown (HELO [192.168.0.8]) ([83.112.101.218]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 1 Apr 2005 10:15:06 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0c82e54162d5ada7ff39ac962d96f2cd@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state Date: Fri, 1 Apr 2005 12:15:03 +0200 To: Eric Scheid X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 1 Apr 2005, at 01:38, Eric Scheid wrote: > > On 1/4/05 9:10 AM, "Henry Story" wrote: > >> The value "alternate" signifies that the containing element is an >> alternative >> representation of the resource identified by the IRI in the value of >> the href >> attribute. > > You do realise you've reversed the directionality of the relationship > here, > right? Yes I thought it made the text easier to read. I did not realize anyone cared. > > IMHO, best not to introduce this ambiguity (directionality) into the > spec. > > Proposal: > ----------------------------------------------------------------------- > --- > The value "alternate" signifies that the resource identified by the > IRI in > the value of the href is an alternative representation of the resource > described by the containing element. > ----------------------------------------------------------------------- > --- > > (yes, I know that "alternate" is a commutative bi-di relationship) Good, but now you are reverting back to the previous relation type. Keep in mind the question: what are we relating to what? My answer is that we are relating a resource to a representation. Your phrasing, as the one in the spec, is relating two resources, which I argued is too strong. I think I can get the direction back and preserving the weakening of the relationship which is the core of the proposal: Proposal -------- replace [[ The value "alternate" signifies that the IRI in the value of the href attribute identifies an alternate version of the resource described by the containing element. ]] with: [[ The value "alternate" signifies that the IRI in the value of the href attribute identifies a resource for which the containing element is an alternative representation. ]] PS. grammarians might want to tell me of it is "of which" or "for which". > e. > From owner-atom-syntax@mail.imc.org Fri Apr 1 05:50:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11371 for ; Fri, 1 Apr 2005 05:50:58 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31Aj3Hn012379; Fri, 1 Apr 2005 02:45:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j31Aj3f9012378; Fri, 1 Apr 2005 02:45:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31Aj2wY012364 for ; Fri, 1 Apr 2005 02:45:03 -0800 (PST) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1DHJe9-0000kM-00; Fri, 01 Apr 2005 11:45:01 +0100 Date: Fri, 1 Apr 2005 11:45:01 +0100 From: James Aylett To: Atom Syntax Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state Message-ID: <20050401104501.GM6334@tartarus.org> Mail-Followup-To: James Aylett , Atom Syntax References: <0c82e54162d5ada7ff39ac962d96f2cd@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c82e54162d5ada7ff39ac962d96f2cd@bblfish.net> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Apr 01, 2005 at 12:15:03PM +0200, Henry Story wrote: > Proposal > -------- > > replace > > [[ > The value "alternate" signifies that the IRI in the value of the href > attribute identifies an alternate version of the resource described by > the containing element. > ]] > > with: > > [[ > The value "alternate" signifies that the IRI in the value of the href > attribute identifies a resource for which the containing element is an > alternative representation. > ]] The problem is that 'alternative', as used here, is not bidi: the statement you're proposing has (for me, at least) the implication that the most important representation is the one at the other end of the rel='alternate' arc. What then makes this more confusing, for me, is that the text still says "a resource", which gives the further implication that there might be multiple /different/ resources for which the containing element is an alternative representation. I'd have thought it would be clearer to have the relation going the other way, so that the containing element is the most important representation. From its point of view, it is - and this is its metadata. > PS. grammarians might want to tell me of it is "of which" or "for > which". I think it's "of which". It's clear either way, though, which is the important thing :) James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Fri Apr 1 06:18:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13151 for ; Fri, 1 Apr 2005 06:18:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31B8RO4020694; Fri, 1 Apr 2005 03:08:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j31B8Rru020693; Fri, 1 Apr 2005 03:08:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31B8RmN020680 for ; Fri, 1 Apr 2005 03:08:27 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 70464 invoked by uid 17064); 1 Apr 2005 11:08:26 -0000 Received: from unknown (HELO [192.168.0.8]) ([83.112.101.218]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 1 Apr 2005 11:08:26 -0000 In-Reply-To: <20050401104501.GM6334@tartarus.org> References: <0c82e54162d5ada7ff39ac962d96f2cd@bblfish.net> <20050401104501.GM6334@tartarus.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state Date: Fri, 1 Apr 2005 13:08:23 +0200 To: James Aylett X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I agree with James. If feels more natural to have the arrow go from the representation to the URI. The unjustifiable intuition would be that the representation "knows" that it is an alternate representation of the resource, but probably not vice versa. Another one would be that the link element is attached to the representation, not to the uri. In short proposal A reads "alternate" as "alternate representation of". Proposal A ---------- replace [[ The value "alternate" signifies that the IRI in the value of the href attribute identifies an alternate version of the resource described by the containing element. ]] with: [[ The value "alternate" signifies that the containing element is an alternative representation of the resource identified by the IRI in the value of the href attribute. ]] I have changed the name of the proposal below to Proposal B to make it easier to discuss. On 1 Apr 2005, at 12:45, James Aylett wrote: > On Fri, Apr 01, 2005 at 12:15:03PM +0200, Henry Story wrote: > >> Proposal B >> ---------- >> >> replace >> >> [[ >> The value "alternate" signifies that the IRI in the value of the href >> attribute identifies an alternate version of the resource described by >> the containing element. >> ]] >> >> with: >> >> [[ >> The value "alternate" signifies that the IRI in the value of the href >> attribute identifies a resource for which the containing element is an >> alternative representation. >> ]] > > The problem is that 'alternative', as used here, is not bidi: the > statement you're proposing has (for me, at least) the implication that > the most important representation is the one at the other end of the > rel='alternate' arc. > > What then makes this more confusing, for me, is that the text still > says "a resource", which gives the further implication that there > might be multiple /different/ resources for which the containing > element is an alternative representation. I'd have thought it would be > clearer to have the relation going the other way, so that the > containing element is the most important representation. From its > point of view, it is - and this is its metadata. > >> PS. grammarians might want to tell me of it is "of which" or "for >> which". > > I think it's "of which". It's clear either way, though, which is the > important thing :) > > James > > -- > /---------------------------------------------------------------------- > ----\ > James Aylett > xapian.org > james@tartarus.org > uncertaintydivision.org > From owner-atom-syntax@mail.imc.org Fri Apr 1 06:24:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13662 for ; Fri, 1 Apr 2005 06:24:38 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31BHLdF023673; Fri, 1 Apr 2005 03:17:21 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j31BHLqq023671; Fri, 1 Apr 2005 03:17:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cmailm2.svr.pol.co.uk (cmailm2.svr.pol.co.uk [195.92.193.210]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31BHKXd023656 for ; Fri, 1 Apr 2005 03:17:21 -0800 (PST) (envelope-from solitude@vkps.co.uk) Received: from modem-2904.alligator.dialup.pol.co.uk ([81.78.11.88] helo=vkps.co.uk) by cmailm2.svr.pol.co.uk with esmtp (Exim 4.41) id 1DHK9K-0001JA-Eq for atom-syntax@imc.org; Fri, 01 Apr 2005 12:17:14 +0100 Message-ID: <424D2DB9.4080600@vkps.co.uk> Date: Fri, 01 Apr 2005 12:17:13 +0100 From: Gary Fleming User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: New syndication format Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Seems that someone has come up with a new LaTeX based syndication format: Tex-Oriented Simple Syndication. It's quite a logical syntax, and comes with some interesting features such as being able to use standard tools to generate pdfs directly. Something worth looking at? From owner-atom-syntax@mail.imc.org Fri Apr 1 06:29:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14021 for ; Fri, 1 Apr 2005 06:29:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31BLRut025041; Fri, 1 Apr 2005 03:21:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j31BLRYE025040; Fri, 1 Apr 2005 03:21:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cmailg3.svr.pol.co.uk (cmailg3.svr.pol.co.uk [195.92.195.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31BLPlP025026 for ; Fri, 1 Apr 2005 03:21:26 -0800 (PST) (envelope-from solitude@vkps.co.uk) Received: from modem-2904.alligator.dialup.pol.co.uk ([81.78.11.88] helo=vkps.co.uk) by cmailg3.svr.pol.co.uk with esmtp (Exim 4.41) id 1DHKDJ-0003TM-GG for atom-syntax@imc.org; Fri, 01 Apr 2005 12:21:21 +0100 Message-ID: <424D2EB0.5070302@vkps.co.uk> Date: Fri, 01 Apr 2005 12:21:20 +0100 From: Gary Fleming User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: New syndication format References: <424D2DB9.4080600@vkps.co.uk> In-Reply-To: <424D2DB9.4080600@vkps.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Gary Fleming wrote: > Seems that someone has come up with a new LaTeX based syndication > format: Tex-Oriented Simple Syndication. It's quite a logical syntax, > and comes with some interesting features such as being able to use > standard tools to generate pdfs directly. Something worth looking at? > Doh, forgot the links: Announcment: http://www.mrry.co.uk/articles/1860/ Screenshot: http://flickr.com/photos/mrry/8030000/ Sample feed: http://www.mrry.co.uk/index.tex From owner-atom-syntax@mail.imc.org Fri Apr 1 08:05:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21873 for ; Fri, 1 Apr 2005 08:05:31 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31CrmKT055504; Fri, 1 Apr 2005 04:53:48 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j31CrmOw055503; Fri, 1 Apr 2005 04:53:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31Crj6F055471 for ; Fri, 1 Apr 2005 04:53:47 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 1 Apr 2005 18:53:39 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 01 Apr 2005 22:53:37 +1000 Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <0c82e54162d5ada7ff39ac962d96f2cd@bblfish.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 1/4/05 8:15 PM, "Henry Story" wrote: >> (yes, I know that "alternate" is a commutative bi-di relationship) > > Good, but now you are reverting back to the previous relation type. Well, my objection is less to do with the value of 'alternate' and more to do with the meaning of @rel, and especially with not introducing special case semantics or ambiguities into the spec. Take for example @rel='feed' ... what directionality does that have? Is an entry which contains a link with @rel='enclosure' an enclosure of the resource referenced by @href? Remember too that @rel is extensible ... do we really want to give a false clue in the spec that sometimes the directionality of the arc can be reversed? What directionality is @rel="http://example.org/rels#next". Is the resource identified in @href the next entry, or is the entry containing that link the next entry, following the entry at @href? Prior art in other specs says the relationship is from where the link is found, and to the thing at @href. e. From owner-atom-syntax@mail.imc.org Fri Apr 1 08:26:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23925 for ; Fri, 1 Apr 2005 08:26:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31DHZGM063474; Fri, 1 Apr 2005 05:17:35 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j31DHZVQ063473; Fri, 1 Apr 2005 05:17:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31DHY2m063461 for ; Fri, 1 Apr 2005 05:17:34 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 48576 invoked by uid 17064); 1 Apr 2005 13:17:34 -0000 Received: from unknown (HELO [192.168.0.8]) ([83.112.108.206]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 1 Apr 2005 13:17:34 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2096236859555a4138b511183da47a30@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state Date: Fri, 1 Apr 2005 15:17:31 +0200 To: Eric Scheid X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 1 Apr 2005, at 14:53, Eric Scheid wrote: > Prior art in other specs says the relationship is from where the link > is > found, and to the thing at @href. I think we are agreeing here. The link is from the representation "...." to the resource identified by the href. That is what proposal A says, I think. Henry From owner-atom-syntax@mail.imc.org Fri Apr 1 13:03:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22392 for ; Fri, 1 Apr 2005 13:03:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31Hq7Tp091799; Fri, 1 Apr 2005 09:52:07 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j31Hq7S5091798; Fri, 1 Apr 2005 09:52:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j31Hq4qD091785 for ; Fri, 1 Apr 2005 09:52:05 -0800 (PST) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.51.122]) by smtp.cegetel.net (Postfix) with ESMTP id 881D667306; Fri, 1 Apr 2005 19:51:58 +0200 (CEST) Message-ID: <424D8A53.3010308@cegetel.net> Date: Fri, 01 Apr 2005 19:52:19 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Henry Story Cc: Eric Scheid , Atom Syntax Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state References: <2096236859555a4138b511183da47a30@bblfish.net> In-Reply-To: <2096236859555a4138b511183da47a30@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: > > On 1 Apr 2005, at 14:53, Eric Scheid wrote: > >> Prior art in other specs says the relationship is from where the link is >> found, and to the thing at @href. > > > I think we are agreeing here. > > The link is from the representation "...." to the > resource identified by the href. That is what proposal A says, I think. Not for me... Taking back Eric's example: ... ... My interpretation is that "...somethingelse.atom" is the next (entry or whatever is defined by the @rel value herein) from the point of view of the entry containing the link element. If you replace the @rel with @rel="alternate", then "...somethingelse.atom" is an alternate representation of "me" ("me" being the entry carrying the link element). If you want to say that the entry is an alternate representation of the thing at @href, then (re)introduce the rev attribute: @rev="alternate", meaning "I am an alternate representation of the thing at @href" where "I" is the entry carrying the link element. One could also think of the @rel="alternate" as a bi-di relation: "we" (the entry carrying the link element and the thing at @href) are alternate representations of the same thing, without telling which is the "primary" representation (maybe neither of both is, maybe the primary representation does not have any IRI). This means that @rel="alternate" has the same meaning as @rev="alternate". Well, finally, I'll go for the last... As we are looking at the relation from the point of view of the entry carrying the link element, it is clear that the thing at @href is an alternate representation of the entry that we know of, but it is not defined that the "primary" representation might be the entry nor that the thing at @href knows of the entry as an alternate representation of itself, whichever is the "primary" representation... Well, in a few words: they are alternate representations of the same thing. Same goes for @rel="related": both things are related. This is told by the entry carrying the link element. The thing at @href might not know it is related to this entry. As for "alternate", @rel="related" has the same meaning as @rev="related". This is because "alternate" and "related" don't define a direction to the relationship. If you bring back the "next" relationship, it defines a direction which is read "from the entry carrying the link element to the thing at @href", it defines what is the thing at @href related to the entry: it is the "next". In other words, with link elements, the entry says "hey, this is an alternate", or "hey, this is related", or "hey, this is the next". Here, I use "an" for alternate and related and "the" for next because *I* have defined the "next" relationship as being a one-to-one. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sat Apr 2 05:38:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12867 for ; Sat, 2 Apr 2005 05:38:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32AFjFb031730; Sat, 2 Apr 2005 02:15:45 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32AFjTG031729; Sat, 2 Apr 2005 02:15:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32AFhdC031713 for ; Sat, 2 Apr 2005 02:15:43 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 73208 invoked by uid 17064); 2 Apr 2005 10:15:41 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.224.251]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 2 Apr 2005 10:15:41 -0000 In-Reply-To: <424D8A53.3010308@cegetel.net> References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/mixed; boundary=Apple-Mail-18-985751431 Message-Id: <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> Cc: Atom Syntax , bloged@above.proper.com, atom-owl@googlegroups.com, Eric Scheid From: Henry Story Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state Date: Sat, 2 Apr 2005 12:15:37 +0200 To: Thomas Broyer X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-18-985751431 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 1 Apr 2005, at 19:52, Thomas Broyer wrote: > Henry Story wrote: >> On 1 Apr 2005, at 14:53, Eric Scheid wrote: >>> Prior art in other specs says the relationship is from where the >>> link is >>> found, and to the thing at @href. >> I think we are agreeing here. >> The link is from the representation "...." to the >> resource identified by the href. That is what proposal A says, I >> think. > > Not for me... > > Taking back Eric's example: > > ... > href="http://example.net/somethingelse.atom" /> > ... > > My interpretation is that "...somethingelse.atom" is the next (entry > or whatever is defined by the @rel value herein) from the point of > view of the entry containing the link element. ok. <...somethingelse.atom> would be the next resource. Though I think the next link was meant for feeds, and has been moved over to the API document. So it is a little unfortunate to be basing your argument on an example that is not in the spec, and that if it were would be attached to the feed. > If you replace the @rel with @rel="alternate", then > "...somethingelse.atom" is an alternate representation of "me" ("me" > being the entry carrying the link element). no. <...omething.else.atom> is a resource, not a representation [1]. So what you mean to say is that <...somethingelse.atom> is an alternate resource of me. But that won't do since "me" is a representation. Hence what we have to say is that "me" is an alternate representation of the <...somethingelse.atom> resource. Now you example is also a little confusing because the type of object that should be at the end of an "alternate" link, would usually not be an atom document, but an html document. So let us for the sake of clarity replace <...somethingelse.atom> by <...somethingelse.html> at the same time as we move from "next" to "alternate" > If you want to say that the entry is an alternate representation of > the thing at @href, then (re)introduce the rev attribute: > @rev="alternate", meaning "I am an alternate representation of the > thing at @href" where "I" is the entry carrying the link element. I really don't see the problem "..." ---alternate---> <..else.html> think of it as a short hand for "..." ---alternate-representation-of---> <..else.html> You don't have to switch the directions of the arrows for this to be correct. As you see it is a relation from representation to resource. Perhaps you are thinking "alternate-representation-of" is some causal relationship and so the arrow points from the resource to the entry representation. Since it is easy to think of as the resources (in http land at least) as causing their representation. But there clearly need be no such causal relation at all between the resource at <..else.html> and the "..." representation. <..else.html> may be a resource that only produces html representation of it. It is none the less true that the entry may be an "alternative" representation of that resource. The relationship is logical not causal. > One could also think of the @rel="alternate" as a bi-di relation: "we" > (the entry carrying the link element and the thing at @href) are > alternate representations of the same thing, without telling which is > the "primary" representation (maybe neither of both is, maybe the > primary representation does not have any IRI). This means that > @rel="alternate" has the same meaning as @rev="alternate". (Again I think here you are mislead by thinking of the realtion as a causal one.) One can't quite think of it as a bi-directional relationship, since the relation is asymmetric. "..." ---alternate-representation-of---> <..else.html> works, but <..else.html> ---alternate-representation-of---> "..." does not. <..else.html> is not a representation, it is a resource. [1] > Well, finally, I'll go for the last... As we are looking at the > relation from the point of view of the entry carrying the link > element, it is clear that the thing at @href is an alternate > representation of the entry that we know of, yes > but it is not defined that the "primary" representation might be the > entry nor that the thing at @href knows of the entry as an alternate > representation of itself, Here we are! As I said above this is not a causal relationship. We are not saying that the ... representation is "known" by the hrefed resource, that it can produce it, or anything like that. We are just saying that it is an alternative representation (alternative is happily quite vague) of the remote resource. > whichever is the "primary" representation... Well, in a few words: > they are alternate representations of the same thing. "They" meaning what? <...else.html> and "..." are not both representations only the second one is. what you mean is that <...else.html> has many representations. Some of these are html ones that it produces, others are atom ones that are produced by others. We have something like this <...else.html> ---representation---> "..." |-----------representation---> "..." | |-----------representation---> "..." If we now distinguish between cause and uncaused ones (call crep and rep) <...else.html> ---crep---> "..." |-----------crep---> "..." | ^ | | | similar | | |-----------rep---> "..." now "similar" is indeed a bi-directional representation. And I think you are speaking of the similar relation just illustrated. So to summarize the whole argument in a graph: --Apple-Mail-18-985751431 Content-Type: image/jpeg; x-mac-hide-extension=yes; x-unix-mode=0644; name="Atom-related.jpg" Content-Disposition: inline; filename=Atom-related.jpg Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAFPAjEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKQsB1oAWiozMg70ecnq KAJKKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUUolU9DQA+ikBzS0AFFJSG RR1NADqKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUU4O D0NADqKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigBK5nxpcldBuIwSN5RDg4yC4BH 4g10x6Vxfjhj/ZrD/ppH/wChrSewGj/wiOh/9A6H9f8AGj/hEND/AOgbD+v+NbNNlljgieWZ1jjR SzOxwFA5JJ7CvO5pdxGR/wAIhof/AEDYf1/xo/4RDQ/+gbD+v+NZ+teKpG0K+udGtrp44rd5BfGM LGCFJG0Py+TjoCPem3nifVI5BbLpsMF2l1bI6PcblMUrEA5C8HKkEduuTVe/3A0v+EQ0P/oGw/r/ AI0f8Ihof/QNh/X/ABrPj8XX9xcQxW2ibxcyTxQM10FDNExDFvlO0HBweTnjHeiw8UXV7cyXMFlc XNo9naziCPZ5kXmeaWPJG77qjGe3FHv9wND/AIRDQ/8AoGw/r/jR/wAIhof/AEDYf1/xq7p2rWeq pIbSUs0RCyxupSSM+jKwBX8RVyp5pdwMb/hEND/6BsP6/wCNZniPw/pemaHPeWdmkNxCUZJEJBU7 15HNdZWH4148JX30X/0NaqMnzLUDds5/OQGrVZOitmBc+la1egMjmfYhNcPPZ2uteLNRF7EJlht4 AgYnC5MucfXA/Ku0vTiA1xekHPirWc/88bf+ctZVnaDsJ7Fj/hFtG/58IvzP+NH/AAi2jf8APhF+ Z/xrWqjf6xaac6RTM73EgJjgiQvI4HcKOce54964uaT6mepX/wCEW0b/AJ8IvzP+NH/CLaN/z4Rf mf8AGsu68S6naahdyNpkn2eCxS6eCSZFaNQ8m45GcsVUfLnHHUVIPEl/HfXcP2GOcHUEtLUJNt4M Aly2V6d/+BEc45r3+49TQ/4RbRv+fCL8z/jR/wAIto3/AD4Rfmf8ayJ/F13JpVzKLA2bNbXRglMq uRLCDuyuMYyDg98cgVq/8JDHZnGqwTWcfG25cAwuOxLjhP8AgWKXv9w1Hf8ACLaN/wA+EX5n/Gj/ AIRbRv8Anwi/M/41rUVPNLuK5k/8Ito3/PhF+Z/xpNASHS/E2pWlqnlwGC3cRgnAYmTJ+pwPyFa9 YVuxHji9H/Trb/8AoUtbUJNz1ZUdzuUO5QadUcHMQqSu0sKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArK1bWJtPvrC0trI 3U167KP3gQIFGSSSDxjNatZMkmn3viG3Rbh3vbEOTHGCypvXGHIBCnHIBIP1oAwE+JdlJHcSxxQS RrbzzwLHdo0riJSxDoBmPcFJHX3x0q7ceLrmySRLrSGW6JgMECXAYyrLJsHOAAwPUdORyaS+8IOm g6jZWN9dyI9nPBaWkjqsURkUgDIUEgE4G4nAq1H4TgMgmu728upw0BWSVkyqxPvVBhQMbup6n16U AUT49t49YWxnitkKzx2kw+2KZVmfb92PGWQMwBbjucYFX9B8Tf25e3EK20caRbuVuA0iENt2yR4B Rj1HUY71MPDqJqcl1DfXkMMs4uJbWNlEbyAAZJxuwdoyobBx05OTT/D0djqQvZLy6upUiaGIzlCU jZlYjcFDN90csSePqSAbFV72a4gti9pa/aZcgCPzAn45NWKKAMX+0tcPTQox/vXyj+Smj7d4hb7u i2I/39RYfyiNbVFAHl3xO/4TGWw06Wwia2mFwUVNLupZHYspPzfIvHyms37H4tg0UyeKb6KTLRhI Nql0O9eWdePXjnr1r2I9K5Txdp8t9p8scDKknDIzLkZBBGR6cUMDoaRlV1KuAysMEEZBFcFP4u8S QsR9k01v+Ayf41F/wmviT/ny078pP8a4fYTEdPceEdPlgmgt3uLO3nRklgt5MRMGBHCEFVPOcqB0 5z0qe+8PW99dzXJmnimkMB3IV+QwszKQCD3Y5zn8K5H/AITXxJ/z5ad+Un+NH/Ca+JP+fLTvyk/x p+yqDOwttAtrWS0eN5ibWSaRNxHJlYs2ePUnH9aqW3hG1tIVhgvL+OMQxQMElCF0j3bQWUAjO85w R0HTnPNf8Jr4k/58tO/KT/Gj/hNfEn/Plp35Sf40eyqAdra6Pa6f5QsE+yxo5d0iAAmJBHzkjJ65 znOR1qW2s3tzGWvLmfZEIyJSvznP3zhR83049q4X/hNfEn/Plp35Sf40f8Jr4k/58tO/KT/Gj2Mw PQ6wvGv/ACKN/wD7q/8Aoa1zP/Ca+JP+fLTvyk/xoudV1/xDYvY3EVhDDMVDsiOWADAnGT14ojRm mmB2+if6hfpWvWbpMZjhUH0rSrtArXv+oNcXo/8AyNWs/wDXG3/nLXbXa7oSK8+1FdU0nWbu808W zrcRxqyzK2QULdCD/tfpWdWLlFpCex1VVL7S7PUgv2uBXZPuSDKunurDlfwNckfFPiIHH2TT/wAn /wAaP+Eq8Rf8+mn/AJP/AI1y+wmRys6H/hHYGivEluruX7Xa/ZHaRwWCZfGDjr855OegpyeHrdL/ AO1CafP2hLkR5XbvWIxZ6Z5XGRnqB05zzn/CVeIv+fTT/wAn/wAaP+Eq8Rf8+mn/AJP/AI0/Y1B2 ZvzeF7OazW2aS4CAXAyGGf327f27bjj+tTf8I/ZyT+beeZeMpyi3Dbkj9NqfdGPXGfeua/4SrxF/ z6af+T/40f8ACVeIv+fTT/yf/Gj2NQLM64WbhgftlycM7YJXB3dB93ovb9c1PDGYYI42keUooUu+ NzYHU4AGT9K4r/hKvEX/AD6af+T/AONH/CVeIv8An00/8n/xpewmLlZ3Fcfq+sDQvE1/etZ3V0iW 1vuS2QMyjMvzEEjjjrUCeJ/ETtj7Lp4/B/8AGtbw/b31zq8+oX/kiSWOOMJCpAAUsc8n/a/StKVK UZXZSTTMzw98aLXV9fg0+SwSxs2DGS7uLkAIApIyMYGSAOvevSLTU7G/XNleW1wD3hlV/wCRrPsf CukWWttrNrZRw30kZjd4/lDAkEkr0zx161Zu/D+kX7brzS7GdvWS3Rj+ZFdRRo0Vi/8ACJaUv/Hu l1a+n2a8miA/BWAo/wCEenj/AOPbXtWh9i8co/8AIiMaANqisX+z9ei/1OuQSf8AXzYhv/QHSjd4 li/g0i5/4HLBn9HoA2qKzrC71Oacx3+mxWyhciSK5Eqk+nKqf07VUuvFllaXl9byQ3ZNjsWV1iyp dwuxFOeWYuAB69ccZANyiufbxhaqY4jY3/2x5zb/AGMRr5ofZ5mD823BXnOce9KnjGweWCMRXeZY nmfMeBAqMVcyHPy7WBB/TNAG/RXPr4ysfs0ks9veW+I0ljSaMK0yOwRSvOOWIHzYIyM4rW06+/tC 18021xbMGKNFOgV1I+hIP1BIoAtUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRWJq1xPqN4NG0+R4ywDXlyhwYIz/Cp/56N29BlvTIBHc3t1rl5JYaTK0FpExS6v1w SGHWOLPG71bovTk/d1rDT7bTLRLaziEUS5OByST1JJ5JJ5JPJp9paQWNrFbWsSxQRKFRFGAoqagA ooooAKKKKACiiigAooooAKrXFsJhgirNFAGJJocbnO0Uz/hH4/7g/Kt6igDB/wCEfj/uD8qP+Efj /uD8q3qKAMH/AIR+P+4Pyo/4R+P+4PyreooAwf8AhH4/7g/Kj/hH4/7g/Kt6igDB/wCEfj/uD8qn g0eOIghRWvRQBHFEI1wKkoooAay7his+50xJzytaVFAGCdAjJ+6KP+Efj/uD8q3qKAMH/hH4/wC4 Pyo/4R+P+4PyreooAwf+Efj/ALg/Kj/hH4/7g/Kt6igDB/4R+P8AuD8qP+Efj/uD8q3qKAMJdBjB ztFX7bT1g6Cr1FACAYFLRRQAUUUUAFFFFABXP6n4Uj1O21WKSdD9vuIrlQ8IdY2jWMAMpPzqTHyO Mgke9dBRQBxf/CLX2nXmmPpx0+GYXck0jW9gI4I18llAKKwY59S2cn04rQtPB8cMc6XN204urWaC 4ITaXaWRndhyccuQBzjjmukooA5Gy8EPZ2dxGkmkpK8KwqYtKRUdQwJ80EkvuxggEDuOeRteH9HO h6e1t5iMGkaQJGhSOIHHyopJwox0z3PTpWpRQBT1C8nso0khsJ7wE4dYGTco9cMRn8Dn2qCy8Rad fXAtlnMN2f8Al2uEMMv4KwBI9xkVp1WvtPtNTtzBfW0VxEedsihgD6j0PvQBZorns3Hhm6hV55bn R5nWINMxeS0diAnzHlkJOOclSRyR93oaACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKZNNHbwSTTOscUalndjgKBySTQBR1rUzplmvkRia8ncQ2sOceZIemfRQAST2ANO0fSxpVj5bSG a4kYy3E5GDLIerew7AdgAO1UdGik1O9bXbtGTenl2MLjBihPJYjsz4BPoAo65rdoAKKKhurqCyt3 uLuaOCFBlpJGCqo9yaAJqKwv7Zv9U40Oy/cn/l9vQ0cf1VPvv/46D2ar+m2NxaeY95qE15NJjJZV RExnhFA4HPck+9AHNXHi3VIY3YwWwE2pS2FqUhlmYCMybnZE5biPG1e/OQOj7XxHrmpXEFpa21rb TtBPK73cEqBvLkVVKodrAMGB56e+Od6fw/p89obdoXVPtDXKtHK6ukrEsWVgcg5Zuh6EjpxWdL4L sZL+3cealrDbyxFY7iVJHZ3VmLOG3NnBzknOaAMs+OL6SwudShtIPsUNrbyqh3tI8k6javHYFhkg EkdBUo8Uax9hmP2Ji8UyKbr+zrhUEbKxLeS2HbayhTgn7wPqK6E6Bphtri3+yIIbiNIpEBIBVBhQ OeMDpjFVx4V00QbNtz5nmibzzdSmbeFKg+Zu3fdJGM4wT60AXNGvW1HSLa6d4HaRMloCShPQ4zz+ B5HSrtQWdnBp9oltapsiTOBkk8nJJJ5JJJOTVfUbXUJnSTTtQS2ZRgxywCWN/rgqw/BqAL9NeRY1 LOwAAySe1eZ/Erxl4k8K6bY7Fs7e4kuNwlgkMglRQdylGX5Rkr0J+tVIvHsvi7wrcQX+kz20rBA7 mMmCUb1BAJ9c/dOeO5oA9OOqWQ/5eof+/gpP7Vsv+fqH/vsVnf8ACN6L/wBAjT//AAGT/Cj/AIRv Rf8AoD6f/wCAyf4VzfWV2A0f7Vsv+fqH/vsUf2rZf8/UP/fYrO/4RvRf+gPp/wD4DJ/hR/wjei/9 AfT/APwGT/Cj6yuwGj/atl/z9Q/99ij+1bL/AJ+of++xWd/wjei/9AfT/wDwGT/Cj/hG9F/6A+n/ APgMn+FH1ldgNH+1bL/n6h/77FH9q2X/AD9Q/wDfYrO/4RvRf+gPp/8A4DJ/hR/wjei/9AfT/wDw GT/Cj6yuwGj/AGrZf8/UP/fYpyajaSMFW4iJJwAHHNZn/CN6L/0B9P8A/AZP8KyPFOiaVaeHbme3 0yyiljKMrpborKQ68ggcU1iE3awHZgg9KWqljP50YNW66ACkpao6ldfZ7aRgcEKSKALm9R3o8xfU VwOiaRHe6Dp9zcX2rPNNbRyO39p3AyxUEn7/AK1e/wCEetv+fvVf/Bncf/F1g8RFE8yOw8xfUUeY vqK4/wD4R62/5+9V/wDBncf/ABdH/CPW3/P3qv8A4M7j/wCLpfWIhzI7DzF9RR5i+orj/wDhHrb/ AJ+9V/8ABncf/F0f8I9bf8/eq/8AgzuP/i6PrEQ5kdh5i+oo8xfUVx//AAj1t/z96r/4M7j/AOLo /wCEetv+fvVf/Bncf/F0fWIhzI7DzF9RRvX1rj/+Eetv+fvVf/Bncf8AxdMl0C3SJ2F5qwIUn/kJ 3H/xdH1iIcyO0zmlrzKb4rad4b8M6cty8l/qrWcTNCrc7igOXbtnr3PPStTwZ48v/FHh9bpNGluL oSukhhKRwIQcgFnbP3SucA10FHc0VifZ/EF9/r7y002M/wAFqnnyD/to4C/+OGrmnaTHp7vJ9ou7 maQYaS4nZ8/Rfur/AMBAoA5W+1vW4RdSRXDSCXVf7Pgjhhj3RL1LZcgFjjaMnHI6mi01XW7/AFGy 02XUDYlvtgeUpA8riMw7MhSyKw3sCPQHgcY6+bTbK5tpreezt5IJm3SxtGCrt6kdzwOaz7jwnpNz cWRksrY2tpDLFHamBTH87IScYwCNn/jxoA5hfFesy6bd6ok8flWmlQ3PkiIYllfzF3ZPIT5Q2M/i Oc2F1bxAkd1aFpjMrwGMytaLdMH371RVYpnCZXdjPzdcZrslsrVQ+22hHmRiJ8IPmQZwp9QMnj3N VE8O6PHYPZJpdktq7B2hEChSw6HGOowPyoATw7evf6LDNLM80oZ43Z4hG25XKkMo4DDGDjjIOOK0 6y7+7i8O2MLxWaLp0TYmMWFFun9/aByoPXGMDJ5xWmCCAQcg0ALRRRQAUUUUAYnjHB8JalGP9ZNF 5MX/AF0chU/8eK1t1gzN/bfiKOBObLS3EkzdpLjHyJ/wAHcfcp6Gt6gAooooAKKKKACiiigAoooo AKKKKAE6VDcXtvaRmS4mjijHVnYKB+JrP17WP7LsjJHGZp3ZY4YgcGSRjhVz25PJ7DJ7VRsfDkOV utYEeoaiRlpZV3JGf7sanhF7ccnuTWdSoobgXT4s0Mf8xfT/APwJT/Gj/hLdD/6C+n/+BKf41P8A Y7b/AJ94f++BR9jtv+feH/vgVj9Z8gIP+Et0P/oL6f8A+BKf40f8Jbof/QX0/wD8CU/xqf7Hbf8A PvD/AN8Cj7Hbf8+8P/fAo+s+QEH/AAluh/8AQX0//wACU/xrCvPE2ka/qRtJNTso9KtXBm3zoPtc g5CDnmMcEn+I8dAc9J9jtv8An3h/74FH2O2/594f++BR9Z8gIP8AhLND/wCgvp//AIEp/jUp8SaQ LV7k6lZ+Qn3pBMpUegzmnfY7b/n3h/74FUr7w5pl+yySWkcdwhzHcQqEljPqrDn8Oh75prErqgF/ tjUNV+XRLIxxH/l8vkZE+qx8O/47R6E1La+HIFuEu9Slk1K8Q5WW4xtjP+wg+VPqBn1JqpoOpXaX E2l6tIkl9ahT5yLtWeNs7ZAueDwQR6g9iK6IHIzXQmmroBaKKKYBRRRQAUUUUAFFFFADJIo5CrOi sUOVJGcH2rjPHBP9nMP+mkf/AKGtdqehrivHH/IPP/XWP/0NaT2A6usvW/EFtoS24nSSSW5cpDGu F3N6FmIVfxIz2zWpTJYo54mimjWSNhhkcZBHuK81eYjl9X8Savoy2rXdnYqb6Q29vGs5JjlbHll2 OMr97dgccYJzUUWravZ6nfuz28tkNVitCr7y48xIlynOFUMwOOc5PTvsf8Ino2yRPsSmN43i8sux RFbG4IucJnaPu46VaGi2IjZPJJD3CXLZkYkyJt2tknPGxfrjnqavmiBydn4g19NPiQPYzzeRd3Ty yxuOIpQoUAN3yeewx1xzLNr+qXAhhufJgkkk0+5jNuWGElm2mNjn5vu4JGAQTxXRw+HtNgL+XAw3 pLGQZXICyMGcAE8AkA8dO2KV9A06R0Zrf5kSJFIkYYETFo+/Ykn375o5o9gKUXiR7TU7fTNZtlgu 7g7YWt5BLHJ+HDr+K4HrW9VKy0ew06KRLS2SLzP9Y4yXf3Zz8xPuTmg6RaGLy8T7fKSH/j4kztQ5 XndnPPJ6nuTUuwF2sPxr/wAilffRf/Q1rcrC8a/8ijf/AO6v/oa0Q+JAaWinMC/StasjRP8AUL9K 169IYVg+I2K2cuP7p/lW9XP+JP8Ajyl/3T/KgDO8M/8AIq6T/wBeUP8A6AK0ZZY4ImkldY41GWZj gAe5rO8M/wDIq6T/ANeUP/oAqzqWmWurWhtr2LzIiwbG4qQRyCCOQRXmPcyKDeKtNUCUNK1oZFjN 2IyIFLZx85wCM4GRkZIqlJ4xWG6d2srprIWSXmUi+dELOCzZPTCqQOvJ49LN54cnv7U2F3qcs+nO wMkUkY8xlGfk8xccZ29icDGeaQeHJntLuK41AzSXOnixMpiwcDzMOeeThxnpyM98CvdHoN/4SpY7 u8hmsbkiK8W0g8oKxmYxCQd+O/XjBX3xFL4yhk065mtba5jkW2nlha4iwjvEDuTg5yDwe3BwatJ4 ddNS+0/alMYu0uwnlc7hB5JGc9CNp6cYPXPEM/hTz9PW2+2Y2rdjd5Wf9fu7Z/h3fjjtR7oaF+31 6ykuRazSG3ujwscymPzPdCeGH0JrSrGuPDq6kDHq11JdWoI22qjy48Dpux8zH6nHtV9YbwMCbqIj c5I8nqD9wfe7dz39ql26CLVMn/1En+6f5UQrIkEazOskoUB3VdoY45IGTj6Zon/1En+6f5UgMTwh pWn6p4a01dQsLW6H2WL/AF0Kv/CPUV12k6Lp+h28kGl2kdrDJIZWSMYBYgDOPoB+Vc34B/5FzTf+ vaP/ANBFdlXqGoUUUUAFFFFABRRRQA10WRGR1DIwwykZBHpWLoDNp1xcaFMxP2UCS0Zjkvbn7oz3 KEFfoFJ61uVi+IoJIo4NWtUZ7nTmMhRRzLCeJEHqcAMB/eRaANqio4J4rq3jngdZIpVDo6nIZSMg ipKACsnW9RmhMWn6dtOpXeRFkZEKD70rD0XI47kgd+Lmp6hDpWny3lxuKRj7qjLOxOFVR3JJAA9T VPRNOmtxLfahtOpXmGmwciJR92JT/dXP4kk96ALem6dDpVhHaW+4omSWY5Z2JyzMe5JJJPqat0UU AFFFFABRRRQAUUUUAFFFFABTXOFJp1NkGUNAHJahJ5/jDR4nPyI00oHqwjIH6M1dJXHeJ/Osry01 K3jMktlN5uwdXXBV1HuVY498V1On6hbapYxXllMs0Eoyrr+oPoQeCOxFceIT5rgZ3iXW5dHgtFtk 3T3c/koxheUJ8rOWKJ8zcKeB69hmsRfEOqS3MdwtpP8AaEsbn/RvLkRZWWaJVkEbYb7pJAPPJANd VqOmW2qQLFdK5COJEZJGR0YdCrKQQeSOPU1U/wCEY0r7OIfszbRG8e7zX3YZw7HdnO4sobdnOR1r JOKQjBbxjd+TbQRtby3U00iGWOyuGCKiqTugH7xW+dRgnHfParup6re3PgKS/WGW0vSq/uzujIYS AdwGAPuM4NX28L6a8IQrcCQSGXzxcyCbcVCk+Zu3fdAGM4wB6VN/YGnfZVtvIIgWMRCMSuF2htw4 z1zznqfWneIGBc6vrf8AaMFjJNZxzRahFHI8UTbZI3jZsYLZBGD354PHSmQeI/EN39k8qLTEF5DP NGWWQ+WImA5553bh0xj3rpLjRLG5neeWFvNeSOUusjKdyDCkYPHBI9880sOi2EHkeVBt+zxyRRfO x2q5BYdeclR19KOZdgMzwzqkurXd5cuziOWC1mSIsSI98W4gfnXQ1T0/SbPS1K2UPlgxxx/eY/Ki 7VHJ7CrhIAJJwBUNpvQDndaf7P4t0eROGkguI291BjI/I/zrqLdt0QNcHDqC+IvFLX1v81lbRm3t 37SZbLuP9klVA9duehFd1ajEIrvpJqCTGT0UUVoAUUUUAFFFFABRRRQAh6Vy3irTnv7GSJG2McMr YzgggjjvyK6qoJ7cSjBFAHnFx4g8UwuQLizb/t1P/wAXUP8Awk/iv/ntZf8AgKf/AIqu9k0WNzkq KZ/YUX90VHs4dgOF/wCEn8V/89rL/wABT/8AFUf8JP4r/wCe1l/4Cn/4qu6/sKL+6KP7Ci/uij2c OwHC/wDCT+K/+e1l/wCAp/8AiqP+En8V/wDPay/8BT/8VXdf2FF/dFH9hRf3RR7OHYDhf+En8V/8 9rL/AMBT/wDFVzy/FrWoruS11CW1tJ42KsGtSy5+ob+let/2FF/dFcvr/wAJ9P1/XIdRlmeHbGVl jjUfvD/Ccnpj3BzxR7OHYDLi8V+J5okkiuLF43AZWW2JBB6EfNUz3PiDXrVrO9urZbeUr5nl22GI DA4BLcdPStqOI6RIltrscccZIWK+RcQv6Bx/yzb6/Kex7V0UOkxxkEKKPZxXQB2lRGOFQfStKo44 xGMCpKsArF16EzW0ijupFbVQXEAlUgigDzK08Q6toumWli+j20ptoUh3resN21QM48vjpTv+E51P /oBQ/wDgaf8A43XZXGgxysSVFQf8I1F/cH5Vl7GHYXKjlP8AhOdT/wCgFD/4Gn/43R/wnOp/9AKH /wADT/8AG66v/hGov7g/Kj/hGov7g/Kj2EOwcqOU/wCE51P/AKAUP/gaf/jdH/Cc6n/0Aof/AANP /wAbrq/+Eai/uD8qP+Eai/uD8qPYQ7Byo5T/AITnU/8AoBQ/+Bp/+N0f8Jzqf/QCh/8AA0//ABuu r/4RqL+4Pyo/4RqL+4Pyo9hDsHKjlP8AhOdT/wCgFD/4Gn/43UieLtVulaNdEt1LDGTfN/8AGq6f /hGov7g/KpoPD8cbZCCj2EOwcqIPB9jJYaPZ28uC8MKIxHQkKAcV1FVra2EKgAVZrUYUUU122rk0 ABYL1rIv/FWl6fObeS58y4HJggRpZB9VQEj8qytUvrnWdUk0yzmeC1gA+1zxthySMiJD2JByW6gE Y5ORYs7G206AQ2cCQxjnCjGT6n1PuawqVlB2RLlYcfGCn7mk6qw9fs+3+ZBpP+EvP/QH1X/vyv8A 8VU9RzXMNvt8+aOPdkLvYDOAScZ9gT9Aay+sS7C5mM/4S8/9AfVf+/K//FUf8Jef+gPqv/flf/iq mR1kRXRgysMhgcgj1ps00dvC8s0iRxoNzO7ABR6knpR9Yl2DmZj6Rr8+ky3Fomj6m2n7vMtv3S7o txJaPG77oPK+xx2GdT/hLz/0B9V/78r/APFVPRR9Zl2DmMa81+a+1qzlm0fU/sVoDKq+UuXmPCkj d0Ubj9WB7Vpf8Jef+gPqv/flf/iqnqE3duLZ7gzxCBN26TeNq7SQ2T0GCCD9KPrEuwczE/4S8/8A QH1X/vyv/wAVR/wl5/6A+q/9+V/+KqZmVMbmAycDJ6mlo+sy7BzEH/CXn/oD6r/35X/4qnDxjCnM +napCvdjaM+P++M05Zo2meJZEMiAMyBhlQc4JHbOD+Rp9H1mXYOYu6brun6srGyuopinDqp+ZD6M vUH61oA56VymoaRb37LKd0N3GP3V1Cdskf0PcexyD3FW/D2sT3DTWOo7BfWpAkKDCyqc7ZFHYHB4 7EEc4yd6dVT06lJ3OhopAcilrUYUUUUAFIeRS0UAY+raeLiMjFcJNo+oaTdSTaRd3Fm8hy4iwVc+ pRgVJ98Zr1FlDDmqsunxydQKTSe4Hmh1PxaD/wAhd/8AwGi/+JpP7U8W/wDQXb/wGi/+Jr0Q6NEf 4RSf2NH/AHRU+zj2A88/tTxb/wBBdv8AwGi/+Jqnq3ibxRo+my3s+rOY48ZAtosnJA/u+9en/wBj R/3RXK/ETwZqGveHUs9IEIfzg8vmMVygVuBxzzij2cewGHBrXim5t454dZZ45FDKwtouQen8NP8A 7U8W/wDQXb/wGi/+Jra+HXhW/wBM8JwRarLDLvxLAEzlEYBtrZA5yTXU/wBjR/3RR7OPYDz0an4t /wCgu/8A4DRf/E1yHirxP4msbkW+vyyXlhLkoq4iSQejbQM/Q5r3IaNF/dFV9S8KabrNi1nqVqs8 DENtJIII6EEYIP0pqEV0Awfh+y6toFtqAgSHzM/u1kD7cHA5H0zjtmu4RdqgVkT+GLMy/aLFn068 AAE9rhdwHQOuNrj/AHgfbFR/2vf6R8uuWwkgH/L9ZoWTHq8fLJ9RuHqRVAbtFRW1zBeW6T2s0c0M gykkbBlYeoI61LQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFADJI0miaOVFeNwVZWGQ wPYisP8As2+0D59FzdWI+9p8j8oP+mLnp/uNx6Fa36KAKWm6ra6tA0lq5LIdssTqVkib+6ynlT9a u1l6nokd9Mt3bStZ6jGMR3UQ5x/dcdHX2P4YPNR2GtSC7XTtYhW1v2z5ZU5iuQOpjY9+5U8j3HNA GxRRRQAlFLRQAlFLRQAlFLRQAlFLRQAlFLRQAUUUUAFVL+QpCSPSrdVb2PzISKAOR8NSB11JT/rV vpDJ684K/wDjpWtquR1IXmhaw2o2SeYrgLcQE4EqjoQezDnB79D2I2NM8TaXquEguVjn7283ySD/ AICev1GR71w1qbUm+hEka1edz3vm3drK2pTPqImvDNbGXIgKxTBcL/DgYx/eznmvRKTABJAGT1rO MrEnFW2oyjXLPzL55SxgQQx3JV03RrndCRh1JJbeORz6GslNRNz4VUxalPfTXGjyvfJJMXETBV2k j+E5JHbIyecZr0vaN27AzjGagsLKHTrCC0twRFBGsaZOThRgZP0FVzrsO5yF1rMqeKU8i5Kn7d9n aKW7PI2EAeSBgKWwQ5OSSPUVW/tOZPD/ANps9WuJr94Izfo8pK27NIgkJOD5RUFxgDgAnHy13+Bn OBS4HPHWlzrsFzg4b+QpFHd6ssWlNelDcQ3zybcRZEZnZVyC3OQTz8ue1PiuYm+Gt9bi53zPFeSK X++6iZwXI+pH513Gxdu3aNvpjilo5/ILnDarb/Z76W0nvrt7WC5sZ98ty2ULu6sd2eB8oOOgPTFO s7e5vbuw83VNQC3c94kqpcFRtR22Bcfdxgcjk9OnFdvRRzhc5Xwdcy3k73Fw5kmk02yZ3PVj+9yT XVUUjMEUsxAUckk8Cpk7u4haxlmA8cKI+qWIEuPd/k/k/wCdV9S8Y2NuWg04jULzoEhbKKf9t+g+ nJ9qf4W06cSyXV25lurh98smMZPYAdlA4A9K6KFN35mVFHcRHMYNSUyIbUAp9dZYUUUUAFFFFABR RRQAUUUUAFNkbZGzYztBOKdUF9cNa2FxcIm9oomcL/eIBOKAI9Jupb7R7K6ni8qaeBJHj5+RmUEj n0Jq3UNpK89lBLKmx3jVmX0JGSKmoAKKKKACiiigDGufDsa3D3ekzvpt253O0SgxSn/ppH0b6jDe 9RjX59MOzxDbC2XoL2HL27e7HrH/AMC4/wBo1u0hGRg8igBI5EljWSN1dGGVZTkEeoNOrEk8OC0k abQrk6bKx3NCF328h/2o8jH1UqfUmkHiGTTjs8QWpsh0+1oxktm+r4yn/AwB7mgDcopsciSxrJGy ujDKspyCPUGnUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFcp4g1rUNH155ImjktI9NeX7MVILy eYqqd2eBlhzjgZ/Bl14g1qxvDpsiWE16ZbcJMqOkWyUyDldxOVMZ78gjpQB11VtQ0621S0a2vIhJ ExB6kFSOjAjkEdQRyK5vSfEWrz6jaRahFYiCe7uLH9yHDb4g538kgKfLI29RxyaTXPFGoaIUWT7J JLBBHLcxQwTSFiWIOGHES4Bwz5z0xxQBqadc32n3o0zUxJcIwza3wXiQD+CTHCuPXgN2wcitquDb XNQsNZlma6L2MM1/JLCwLMyxqjBVOeMZ449afH4y1j7BLK1gjyskDxM1rPBGrPKiGMtIPmOHBDL6 HjjkA7miuRl8Q63bXN150entb2N3bW0+1XDSeaItxXnC7TJkZzkccYyY5/Fd8+pTWkDW5SUXMcMi W8pETxqxBMhwjn5TlV+6eMmgDsqK4CLxnq0FnbxpB9snt7CC4n2WU8jXLOpbYpQEIcDq2QSegFd8 DkA+tAC0UUUAFFFFABRRRQAUUUUAFIy7hg0tFAGNqWlLcqflFcfqfg+K4yJIUdfRlBFekEA9ajaB G6igDyX/AIQhE4SMoPRWIH6Un/CF+0n/AH23+NermyjPYUn2GL0FFgPKf+EL9pP++2/xo/4Qv2k/ 77b/ABr1b7DF6Cj7DF6ClYDyn/hC/aT/AL7b/GubSK2m8bDQoSzYRgzCRv8AWAbsdewB/H6V70bC IjpivN9C+F1jaeN7m9tNQvP+JfOhPnFXMrMm5gTgdmHv1osBR/4Qv2k/77b/ABo/4Qv2k/77b/Gv VvsMXoKPsMXoKLAeU/8ACF+0n/fbf40f8IX7Sf8Afbf416t9hi9BR9hi9BRYDyn/AIQv2k/77b/G np4GidgZIBJj+/8AN/OvVPsMXoKUWcY7CnYDjNK8LJBtwgAHQAV1tlZLboABVtYlXoKdQAUtFFAB RRRQAUUUUAFFFFABRRRQAVV1O5kstLu7mGPzJIYXkRP7xCkgfjirVR3DvHbyvEoaRUJVT3OOBQAQ OZYI5GG0soYj0yKkqtpt019pdpdPGY2nhSQof4Syg4/WrNABRRRQAUUUUAFFFFAGXrfiC00BbVrw SkXM6wr5ag7c9XbnhR3PvV6W5t4t6zTRJtTzHDsBhP7xz2965zXPDd54j1e5E1zJZ2K2ZtYiixv5 vmcynDA7fuoAeDwaS5h1e58MxxTaUr6n9niWeUmJ9xEg3hQTgnALgH5ckA9xQA7ztA0iS3vtPufI trt3y1nMptjtRpGLLkqOFPKjOetbFvr2mXNvZTJf2wW+UNbhpVBkz2AzyfYVyVl4f1Z7yQz21xse /kuBJcvDuKPZmLJEeBneOQB3HXk1Sl8L6rLB5UtpfgXOm29pshktQImQMGDs4YqMncGTPXpkCgDv pNW0+F3SW/tUdPvK0ygr9eeOhpH1nTY7KO8fUbRbWQ4SczqEc+gbODXOHwxIzuz2MbtJrYu5GbaS 8Q6Mfp6fpVefRdUguGSCykFs93dSBrYQGRQ+zbjzMqqt8+4gFunHNAHULrunNqdxYC7hFxbwLcSq XHyxtnB/TJ9AV9RVq1vLa+t1ns7iK4hb7skTh1P0I4rz7/hGNYfRUt2s5Vl/svT4XKyREs9vMxkT kkZZWG3IKno2OldR4V0+ezW/nuI7yNrqcPi6aHecIq7isShVzjHUk4BPpQBv0UUUAFFFFABRRRQA UUUUAUb7RbHUpvNu4TI3kvAfnYBo3xuUgHBHA69O1QW3hzTrYLiOaRxKk3mTXEkj7lBC5ZiSQATx 05NatFAFGPRrGKSF0gw0M8lyh3txJJu3t177246c8VSuPCGkXUZjmhnZDCsLr9qlAkVc7d3zfMRk 4JyffgVt0UAZh8O6aZFc25LLI8mTI53Fxh888ggDIPHHSqJ0LRNMmtrR4J3N5IsURknkk2eVmVVB ZiVUeXnA445roaxdV/feJtCgHWNp7o/RYzH/ADmFAFyXRrGcXPmQZ+0zRzy/O3zOm3aevGNi8Djj 61VTwrpUd0k6wS743d41NxIUQvneFXdgA7jkAY/IVsUUAYjeD9HZIkME2yOJYSn2mXEkaklUcbvn AycBs8HHTituiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACsXQfm1LxBJ/e1AD8r eEf0NbVYvhzl9Xf+9qMv6BR/SgDaooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooApaTeTXtm0lzD5MyTSxMuCB8jsoIz2IAI+tXapRXVydZubWWAi3WKOSGYKcMSWDKT0yMA/Rq u0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAQ3NrDdxGOeMOp9eo+h6g+4rKOj6jYHdpGqyMn/Ptf 5nT8HzvH4lh7Vt0UAYf/AAkMtjxrem3FmB1nhzcQf99KNyj3ZVFatpe21/brPZ3EVxC3SSJwyn8R U9ZV34b066uGuY43tLtutzaOYpD/ALxX730bIoA1aKw/L8Qad/q5rfVoR/DMBBPj/eUbGP8AwFfr T4vFFisqw6is2mTscBL1fLDH0V8lGPsGNAGzRSAgjIOQaWgAooooAKKKKACiiigArD0v/T/EWp6h 1ih22MB7fJlpCP8AgbbT/wBc6ua5qLaXpE1xEge44jgjP8crEKi/ixH4U/SNOXSdKtrJWLmJMM56 ux5Zj7kkn8aALtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABWL4Y+azvn /v6jdfpKy/8AstbVYvhLnQfM7S3V1KPo08jf1oA2qKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKAKWpy3kEUMtlGJds6CaPHLRk4Yj3Gd3vtI71doqlpi30cMseossjpKwjlGB5 kZOVJA6EA4PuM96ALtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUyWKOeJo5UWSNhhl YZBHuKfRQBiHwxBakto1zcaW39yBgYT/ANsmyo/4CAfek+3a3p3F9YR6hEP+W1gdr/UxOf8A0FmP tW5RQBnafr2nanKYba5UXCjLW8qmOVfqjAMPyrQyK5/xktqfD17PcWtvcSW1vJLF5qbtrqpIIPUc jsQaoad4f1i0gUReJrtoioISaFZCv0Zst+ZNROcYbgdfketGR61zn9laz/0MD/8AgJHR/ZWs/wDQ wP8A+AkdR7eAHR5HrRketc5/ZWs/9DA//gJHR/ZWs/8AQwP/AOAkdHt4AWLsjUfFlpa5zDp8X2yQ esj7kj/ICU/XbW3ketcpD4e1OC6ublNfk825KmQm1jP3RgAeg/xNWP7K1n/oYH/8BI6PbwA6PI9a Mj1rnP7K1n/oYH/8BI6P7K1n/oYH/wDASOj28AOjyKWuQ1WHW9L0e9vk1wyNbQSTBGtUwxVScH8q 6WxuftMCOcZZQTitIzU9gLVFFFUAUUUUAFFFFABRRRQAUUUUAFFFFAFe+vYdOsLi8uW2w28bSuR/ dUZNQabrNrqel29+haGOc7Ak+FZX3bShGfvBgRj1qp4n0+71ezt7C1Zo4prhTcTDafLjX5+h65ZV XGDwTmqej6XfaRNfW1zC+o20l5HcwzN5SkM5/eHbwBtYb+Bzu4yaANW617T7W3v5BdRTPYRPNPDD IrSKFGTlc8HjvimW/iTSrn7cVvYEFg6pcmSRVEZKhhk598fUEdq4yfQddufN32M4d7O+gZAbdIVe Vcrs2ncQSBkuc5I4HOLeo+H9Ta7uJYra4EaanDeZtzCWlQWqxHaJMruV1zhhjHIOegB2R1SxVYWa 9tgs4BiJlXEgJAG3nnkjp6iqmhy6ZbacljYahBcrZxgOVmVmAPOWx0z1rn9I8MTxXtrcXFnJtS3v GX7Q8TPFJLKjLwgCqSAx+UYGSM+rE8N39lpdklnp0HnR6BJZyxts2tMfKwrc/N0k56dcnmgDo5/E 2j29rFctqNq8Es626yRyqy7yemQfz9Kux6hZy3klpHdQPdRDLwrIC6D1K9RXERaJq32m5neyvJka 5sp0E7W6uwjYhxtQhQQMYHcDrnipdB8O6haa1a/a474i0uriczF7cQv5m/BG1fNYneMhiMEdTgZA O6ooooAKKKKACiiigAooooAKKKKACiiigArB8Q+Jf7DubWBbeKSS4V2XzrgQK20r8isQQXO7hSR0 PNb1ZWtaEutLse9uoInjaKWKPYySq3qHVgCOxGDzQBRPimcX06tppWxt71LKW5acBg77NpCY5GZF B54z35rOg+JenSNJI6w/Z/KmliMNyskrCMEndGOUyASOT74q5ZeEiL67e6urgWjX6XUVqrKY32Km xmJXdkMmcbsHaPxsw+EbaO3ltJLy9l09opIUs2dRHGr9QMAFsA4G4nFAGfq/ibVbWG2t59Oksbq6 uUiRoCLnKlHc7OAC/wC72kEYG4HJFaWkatczaRFOwe8CmYTSlBDIhQkBWjP8XGDjAyM9DQ/hZZYl M2qahLdxyJLFdu0e+IqrKMALtxh2ByvO4+2JP+EZgOkyae93dtDMswuDuUNOZc7mYhevJxjAHpig DGHjOXUI2itfs0dzDd2aube5W4QpLNsKlgMBsKwI7cYNQw+PZrbT7UahDYrfTmd8SXqwxiOOQp95 hyxPAGOcEkitiPwhALr7RPf3s8h+z53eWo/cyF4wAqAAZJGB1B9eaQeEYoSj2epX1rKhlUSR+WT5 cj72TlCMBuQeo9aAKbeOvMt57uz0uWezhtobgyGUKWEoBRQv97nnnA9asv4quILe9+12EFtdWkqI yy3irCFddwcyFRgdQeCcjjNTXeiabBDLb3N1Og1Aww7nkyS0Y+UBiDydvfJJqS+8MW97fNeC5uYL kzRzq6bDsZEZBgMpH3XPUHnkYoAx18cu8tpe+REulmyvbi5ZZd7BoJFQ7MDDDJ45Gd2eMYOl4c8W Q6/dT2222WeKNJsW92twu1iRgsuMMCOR7jBNNXwVZeSsMtzdzR7bpHWRlPmJcENIrELn7wDAjBB7 44rR0vSpNPaR5tRvL12VUBuGXCqM4wqqBnnk4yfXgUAaNFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQByPjuQr4b1IetrL/6Ca37f/j2i/wBwfyrnfHv/ACLuo/8AXtJ/6Ca6K3/49ov9wfyr lxPQCSs258Q6VaPNHLfQ+ZAB5iId7KScAYGTkk8Dqam1bTU1fTZbKSaeFJQAXgfa4wc9f5g8EVzt 54W1BtOt7KE2LQWc63EPkF7NnIyCrGPODhidy45A+WueKT3Ea8virR4YIZXuzibfsVYnZzsIDjYB uBGRkEZH4GoT4x0pbueN5ikEVtDc/aSjeUyysVXDYx6fn7HFfRvDlxY6ja3kqwxlRcmVBPLM26Qx bfnfJY4jOTx7CqMHhDUIrOG2Z7Rl+x2MEh3tw0E5kOBt5BVjjpyBxzkVaIHQp4i0x7NroXP7pZUh bMbBg7BSo2kZyQ6np3q1ZX9rqVuJ7G5iuIT0eJwwz6cd652bT5Lnx20lvhreCJbiZGBCm5CskfzY 7o+TjONi1Yi8OXLaoNYuZoFv0U7YrRPKjc4OBK/LSD64H+zSaQHRUVTL6jtbENpnEe3Mrdc/vM/L 2H3fU9cVcqQMrxT/AMilrP8A14z/APotqk8PSF7KHP8AcH8qj8U/8ijrP/XjP/6Lal8N/wDHlD/u j+VdWG2YzfooorpAKKKKACiiigAooooAKKKKACiiigAooooAKKKjnnitoJJp5FjijUs7ucBQOSSf SgDM1S4lk1rStPt5HQs73M5U4/dIMYP1d0+oBrXrE0COS7ludauY2SS92rBG4w0cC52AjsSSzkdt wHatugAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAILyzgv7V7e6 jEkT4yp9Qcgg9iCAQR0IqG21OGfUbmwKyR3FuFbbJj94h6OvPIzkeoI57Zu1Be/aBayNZLE1yqkx iXIUn0JHIz69vQ0AT0VBZ3DXVnFM8EkDuuWikHzIe4Pb8RxU9ABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAcn42tpLnQr+KFC8jwSKqjuSpwKpr8QdNt4kSWz1JWVQCPs//wBeurvbUTqQ RXO3PhpJXJ21E6anuBW/4WTpH/PtqP8A4D//AF6jb4oaKsqxGDUfMbkKLfnHr16VnT6Ubu7kstHj SWWM7Z7hhmKA+n+0/wDsjp3I73rPwPDZocBpJX5klflnPv8A4DgVn9XgBP8A8LJ0j/n21H/wH/8A r0f8LJ0j/n21H/wH/wDr07/hFE/uUf8ACKJ/co+rwAb/AMLJ0j/n21H/AMB//r0f8LJ0j/n21H/w H/8Ar07/AIRRP7lH/CKJ/co+rwAb/wALJ0j/AJ9tR/8AAf8A+vR/wsnSP+fbUf8AwH/+vTv+EUT+ 5R/wiif3KPq8AKer+NbLVtB1Cys7LUWmuLaSKMGDA3MpAyc+prpvD0ZjtIlYYIUA1n2nhxIXBC10 VpbiFAK0hBQ2AtUUUVYBRRRQAUUUUAFFFFABRRRQAUVXu7+0sI/MvLqC3T+9LIEH5ms3/hLtIk/4 9J5b49vsUEk4P4oCP1oA2qKxf7Z1O44stAuRno95NHCh/BSzD/vmk+w67e/8feqQWUZ6pYw5cf8A bSTI/JBQBoajqtnpUIlvZ1iDHai8lnPoqjlj7AE1lLZ3fiKeObU4XtdMiYPFZMRvnYchpvQDqE9e W9Be0/QbDTZjcRRGS6YYa5ncyysPTe2SB7Dj2rSoAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKAKVzBef2jb3FrcL5AylxBJ0ZezKcZDA/gQTnsauA5GR S1lRQ2PhuGVjO8NpPOCqNzHCznoMD5VLc8nAJ7ZxQBq0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFU9T1W20m3EtyzZdtkUSLuklbsqqOSf/19KALE00VvC808iRxIpZ3cgKoHUknoKwd934n4 tzLZaQeswyk10P8AY7oh/vfePbHBMkOlXOszJd68qrEhDwacrbkQ9mkPR39vur2yRureoAgtLK2s bWO2tIUhgjGERBgAVLtHpTqKAG7R6UbR6U6igBu0elG0elOooAbtHpRtHpTqKAM3W9SGk6ReXqxi RraB5QhON21ScZ7dKxU1PxJJGrCDShuAOPNk/wDiaTx1KV8NamPW1lH/AI6atwf8e8f+6P5VhWqS haxMnYrf2h4k/wCeWlf9/ZP/AImj+0PEn/PLSv8Av7J/8TV2op7qC2VmnniiVV3sXcKAvqc9qw9v MnmZX/tDxJ/zy0r/AL+yf/E0f2h4k/55aV/39k/+Jp0mq6fFbpcSX1qkLruSRplCsMgZBzgjJH5i oxrmnG/ls/tcImiiSVgXAG1yQvP1x/30vqKPbVB8zHf2h4k/55aV/wB/ZP8A4mj+0PEn/PLSv+/s n/xNSrqNm9v9oS7t2hBC+YJFK5OMDOcZOR+YqdWDKGUgqRkEdDR7eYuZlP8AtDxJ/wA8tK/7+yf/ ABNH9oeJP+eWlf8Af2T/AOJq7RR7eYczMbV9b8U2Ok3N3DFo4METSnc0rcKpJwMDnj1rVtdGfUYl k1PVtQudwB8uKX7PGPYCPaSPqTVDxL/yK2rf9ec3/oBrX8PymSziz/cH8q6KM3NO5UXcntPDej2M nmW+mWqy95TEGc/VjyfzrToorYoKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKjngiuYHhnjSWKRSro6gqwPUEHqKkooAoJe/Z9TXT3tnj jaPdBMPmR8dVJ/hYdcHqOnQ4v01wWRgrFSRgMOo96q6Y18bTbqSRi4RipeI/JIOzAdRkdj0OevUg FyiiigAooooAKKKKACiiigArK1jxBDooLT211LFHGZppYkBSFB/ExJHvwMnjpWrXL+J/Bx8Rzzs9 zbrHNafZgJ7bzjCfmy8fzAKx3YJwT8oxigCVfFoS91G2m0+5L296tnbJHsLXLGJZOMtgYBLckDbj nOQCbxvYxRoVtL+WQxzSPFHEC8QiYLIGycAgn1Oe2cjLZfDN2L2W+hv7dLk3SXkZe3JVXEAhcEb+ VZQCOhB7mo9N8PQXUL3UGpRXJuLe6hkmij+R3mcMWX5jwu3aBk8DrxQBesfFNtqCTmC0vt0cccyo 0QDSxSEhXUZ6fKeuCMciqcniWzikMz2kl3eo9yitb2w3RRRSFWJy2cZx0OWPRewuwaDNaXBuLa9V ZfsUFmC0O4Dy2Ylsbh1DEY7e9U/+EUura4efT9Sjhlla5ErSW5fKSymQAfMMMpJAPIOTxQBr6HfS anoGnX0wRZbm1jmcIMKCygnGe3NX6p6TYf2Xo1lYeZ5v2W3jh37du7aoXOO2cVcoAKKKKACiiigA oopk00dvGZJpEjQdWdgAPxNAD6KxW8W6OWK2t0b1xxtsYnuOffYCB+NJ/bGqXP8Ax46DMo7PezpC p/Bd7fmooAyPHv8AyLupf9e0n/oJrQg/494/90fyrnvGVrrtxod8bm5s418h/wBzbQM7N8p43sf/ AGUVZi8XaEkKK2qW4IUA5aubEJu1iZGjqlrcXunywWl41nM4G2ZVDFefT36dj6GuVvPD94LWOOPT gs0VxHPLc20yySXKrnjM3O4EhgGyPl65xW3/AMJjoH/QVtv++qP+Ex0D/oK23/fVc65l0J1M3SfD 8y6lZ3F1ayGIfapGFy0TMjSGMDIQBQSFc4GcZOTzVKPw3f8A9nx2k1jvD2NhC/zoQDFOWdTz/dYd Mg4Ptnf/AOEx0D/oK23/AH1R/wAJjoH/AEFbb/vqnefYNTNuLHd4wNrBGj2W1L6aJCOJEUxqpHQb v3ZGf+eZqew0a9tr0XtvEmm26hmOn28m8THHAOcIhz/dH/Aqsr4t8Oo7MupWgZzliDy3bmnf8Jjo H/QVtv8Avqj3uwal83VyFYiwlJAjIG9Odxww6/wjk+vbNW6xf+Ex0D/oK23/AH1R/wAJjoH/AEFb b/vqp5X2FYn8S/8AIrat/wBeU3/oBrS8N/8AHlD/ALo/lXL694p0a68O6lDb6jDJLJayoiKSSxKE ACup8OIVs4gRghR/KurDppO5cTeoooroKCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAqlqVg99HEYLmS2uIXEkcicj3Vlz8ykcEf iMEAi7RQBFFcwzvKkUqO8LbJFVgSjYBwR2OCD+NS1SuLaC0nn1SO1kluhDsYQn5pVHIGCQCeuM+p 55qWyvYNRsoru0kEkEq7kYf54Pt2oAsUUUUAFFFFABRRRQAVV1HUrXSrU3F5KI0yFUYJZ2PRVUcs T2A5qlqGueXdGw0yH7bqOAWjDYSEHo0r/wAI9uWPYd6XT9E8m6F/qM323USCBKVwkIPVY1/hHvyT 3JoAqiwvPER36ujWundU08N80o9ZiO3+wOPUnoN5EWNFRFCqowFAwAPSnUUAFFFZs3iLSobxbQ30 L3RYL5ER8yQE8cquSB7mgCTU9UGmrHi0urp3zhLdQSABkkliAB+OT2zWOvjW3N5P/o07WIsra6gn UAmYzMyogXOckgAe+7OBgmzr2gHXprSUSweXAHBhurYyxsW24faSPmXbwTkfMeKz4fBM0FpDCmox 74LO1t43NueHtpC8T43dPmIZe/YigC63jC2TZG1jfi8ac232MRqZVfyzIM4bbgqM5Bx79aXTPGFn qrKILS+USQSTwmSEDzghAdVGc7gWAwQM9sjmi18NzLqcOpXl5HJdi6NxJ5cJRCPJMSoAWJAAOckn Jz0zwWfhp7H+z2ivR5llb3EKsYchjKysGI3dtvTvnqKAB/FMcE88bwXE8wuEghtoYcS5MKykHLYO ASSflA6cnk2vDerPreipfOgTzJplVdpUhVldVyDyDhRn3zVCXwxdDUH1G21CFb43AnDSW5ZMeSsT KVDg87Qw5GOBz309C0t9G0lLOS4+0uJJZGl2bNxeRnPGT/exQBo1lf8ACM6ObprmXT4J52Yt5k6+ awJ9C2cfQVq0UAIqhFCqAFHAAHApaKKAM7UbT7QhGK5K88MCVydtd6QD1phiQ9qAPPP+ES/2aP8A hEv9mvQ/IT0FHkJ6CgDzz/hEv9mj/hEv9mvQ/IT0FHkJ6CgDzz/hEv8AZo/4RL/Zr0PyE9BR5Ceg oA88/wCES/2aP+ES/wBmvQ/IT0FHkJ6CgDibHw0IXB211thbeQgFWhEo7U4ACgBaKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACikJ AHNZOoeIrSxuBaqJbi7YZFvbxmSTHqQPuj3bA96ANeisD+09dl+aLQTGp6C4u41b8l3D9aPtviL/ AKA1t/4Hf/YUAb9Ubqe6tby28m2E1pKxSYp9+Ino+O69j3GQemazvtviP/oDW3/gd/8AYUfbfEf/ AEBrb/wO/wDsKAN+iuWsZfFdsJkn0+2uEMhaItegMqn+EnZzjnB9MZ5GTa+2+I/+gNbf+B3/ANhQ Bv0VgfbfEf8A0Brb/wADv/sKPtviP/oDW3/gd/8AYUAM8ZeNLDwXYQXF8GleeUJHChG5h/E3PYD9 SB3oivrzxTEr6ZI9lpLjP2zGJrgf9MwfuL/tHn0A4auI8Q/D3W/FniGTUdaiEkIASC3gu1QRKO24 oc5OSTgda6rQ7HVvDulRadpuhQR20WSqtqJY5JyeSnqaAOmsNOtdLtRb2UKxRAkkDksT1Yk8knuT yabc6nZWd3a2tzcxRXF2xWCNmw0hAycD6D+XrWPc33ij7LL9m0azE+w+WXvdyhscZG0ZGfcV4/qv g/xfN4iGr+IbmO3mWQMtxO7+UADkDfEGEa/XbQB7hf8AiCwsJ/szStNd4yLa3Qyy/UquSB7nA96r +fr+of6i2ttLhP8AHcnz5v8AvhCFH/fZ+lXtLs7CxtRHp1vBDC3zYiUAMT3JHU+9XaAMT/hF4Lnn Vru81Inqs8u2L/v2m1CPqDWpaWdtYQCGzt4beIdEiQIo/AVPRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABSHgUtNc4Q0AYXiDUbiNYLPTyovryTyYWYZCHBL OR3CqCcd8Ad60dJ0i10a18m1UlmO6WVzmSZ+7O3c/wD6hgVzt9crB4y0aWYgRmSSHJ6Kzodv5kbf +BV2FABRWJ4o8yO2sLhI5pEt76KWUQxs7BOQTtUEnGR0Fc/pumyap4gtLi8srxbZbm+nUTRug+/C YywOOuCQD6e1AHd0VwXh/QxpsOiyyWN0pm0iZNR+RyztiIqrDru++FHXqBS3pmimv7O3sdQP2rUL Ce3228hVYV8gMS2MDHltkE5oA7qSRYomkbO1QWOAScD2HJqC4v7e1s1up3KQsUAJQ5y7BVGMZHLA e1cK4vXt7bT0sr8zW1xqLSt9nkCAMs3l4bGG3b1xgnsOtVrrTnk+W70+/l1T7RYtayJBIVSBfJ3j djaoBEu4Hvz6YAPQU1SykvZ7RLmJp7dBJMgb/VqSQCfT7p/KqkPijR7i1muI7+LyoEEjswK/KTgM MjkE8AjIJ6VRks0tPE+r3X9ns9tJpcZcRQ589g8xZeB8zEEcdeRWNDfBrS51W5069utQWGJIbH+y 7hIrZRIpUDMeXKttZiMn5MhRigDqD4m0oWYuvtX7sy+TgRuXD7d20pjcDt5wR05q/a3MV5bJPAWM bjKllKn8jg1xRtbSe3jvLyTXZJnvfPubm3sprYq/ksi4Qpv8sL8o25OTyeTW5oN/dW+hRDU476Wd YppgzW7GRolc7AwA/wBYUK/L1Jzx1oA36QgMpDAEHgg96ihuVmlkjWOZTGFJLxlQcjPBPX3x0qag DlmgPhfWoUt2I0m/fYkH8NrNtJAT0RgDx2YcfewOmjbeua5zxrOq2+mWw/1019GyDuAmXY/TAx/w IVt2DFoRn0oAt0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAU1hlSKdRQByHinShfW0kbgkN6HBB7EHsR61S0jx4+motn4kjlJT5VvokLBx6uo5U+4BHfjp XaXNssykEVzWpeHEmJIWgDWh8W+H7hQYtb04+xuUBH1BORUn/CSaL/0GNO/8Ck/xrh5/ByO3zRKf qKh/4QuL/nin/fIoA77/AISTRf8AoMad/wCBSf40f8JJov8A0GNO/wDApP8AGuB/4QuP/nin/fIo /wCELj/54p/3yKAO+/4STRf+gxp3/gUn+NH/AAkmi/8AQY07/wACk/xrgf8AhC4/+eKf98ij/hC4 /wDnin/fIoA77/hJNF/6DGnf+BSf40f8JJov/QY07/wKT/GuB/4QuP8A54p/3yKP+ELj/wCeKf8A fIoA77/hJNF/6DGnf+BSf40f8JJov/QY07/wKT/GuB/4QuP/AJ4p/wB8ij/hC4v+eKf98igDvW8T aGoJbWdOAHc3Sf41laj8QtFtVK2Mx1O4/hjtPnUn3f7oH459jXMp4LjDZ8lP++a1bHwssbAlaAKu mx32tay2q6nt89l2RxpkpAmc7V9c9Se59AAB3tpH5cQFVLDTUt1GBWiBgYoAWiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAppUHqKdRQBEYEPak+z R+lTUUAQ/Zo/QUfZo/QVNRQBD9mj9BR9mj9BU1FAEP2aP0FH2aP0FTUUAQ/Zo/QUfZo/QVNRQBF9 nj9KcI1XoKfRQAlLRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/Z --Apple-Mail-18-985751431 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit we have three alternate relations -spec6:alternate is currently what the spec says -A:alternate is the one of my proposal A -tom:alternate is the relation you mention above between two representations. Notice that I should really draw tom:alternate as relation between the "..." representation and each one of the "..." and "..." representations. The problem is that it would not be helpful to express a relation between the different representations as we don't have a good handle (name) on them. So as I explained in previous posts, the problem with spec6:alternate is that the relation is too strong. In the graph I show some nodes in yellow and others in green. The green nodes are grouped together because they represent a later stage in time when <..else.html> was displaced to . As a result perhaps a few links had to be changed in the html and xhtml, and so has different html and xhtml representations. It also comes with a different "..." representation (which has a different timestamp for example) and a different A:alternate relation. But the id of both "..." representations is the same. Now to say that we want a spec6:alternate relation would say that the resource is an alternate to <..else.html>, which it is not really. That would seem to say that the later "..." representation is also in the same sense a spec6:alternate to . I think we are much clearer by sticking to A:alternate. > Same goes for @rel="related": both things are related. This is told by > the entry carrying the link element. The thing at @href might not know > it is related to this entry. As for "alternate", @rel="related" has > the same meaning as @rev="related". rel:related is a different relation. I have not checked carefully what I think of it yet. But there is nothing a priori wrong with relations that relate the id of the entry to another resource. We just have to ask carefully if that is what the authors of the spec really intended. > > This is because "alternate" and "related" don't define a direction to > the relationship. > If you bring back the "next" relationship, it defines a direction > which is read "from the entry carrying the link element to the thing > at @href", it defines what is the thing at @href related to the entry: > it is the "next". > > In other words, with link elements, the entry says "hey, this is an > alternate", or "hey, this is related", or "hey, this is the next". > Here, I use "an" for alternate and related and "the" for next because > *I* have defined the "next" relationship as being a one-to-one. I think I have made my point as clearly as I can now. Let me know if that explanation has helped. Henry Story http://bblfish.net/blog/ [1] http://www.w3.org/TR/webarch/#id-resources --Apple-Mail-18-985751431-- From owner-atom-syntax@mail.imc.org Sat Apr 2 07:26:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18367 for ; Sat, 2 Apr 2005 07:26:38 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32CH2hL071687; Sat, 2 Apr 2005 04:17:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32CH2FW071686; Sat, 2 Apr 2005 04:17:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32CGxCp071651 for ; Sat, 2 Apr 2005 04:17:01 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 2 Apr 2005 18:16:55 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 02 Apr 2005 22:16:52 +1000 Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2/4/05 8:15 PM, "Henry Story" wrote: > no. <...omething.else.atom> is a resource, not a representation [1]. So what > you mean to say is that <...somethingelse.atom> is an alternate resource of > me. Firstly, why is "... a representation, while " ..." not a representation? Secondly ... "alternate resource" ... wha? A resource is an abstract thing, reified by representations, right? e. From owner-atom-syntax@mail.imc.org Sat Apr 2 08:13:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21157 for ; Sat, 2 Apr 2005 08:13:30 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32D3FOG091094; Sat, 2 Apr 2005 05:03:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32D3FfT091093; Sat, 2 Apr 2005 05:03:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32D3EAD091073 for ; Sat, 2 Apr 2005 05:03:14 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 86551 invoked by uid 17064); 2 Apr 2005 13:03:13 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.224.251]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 2 Apr 2005 13:03:13 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state Date: Sat, 2 Apr 2005 15:03:09 +0200 To: Eric Scheid X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2 Apr 2005, at 14:16, Eric Scheid wrote: > On 2/4/05 8:15 PM, "Henry Story" wrote: > >> no. <...omething.else.atom> is a resource, not a representation [1]. >> So what >> you mean to say is that <...somethingelse.atom> is an alternate >> resource of >> me. > > Firstly, why is "... a representation, while " > ..." not a representation? I don't understand. Are you asking me? I am asserting that ".." and ... are both representations. I have put all representations in rectangles in the attached diagram of my previous email, just to make this point. > Secondly ... "alternate resource" ... wha? Argh. I was trying to show what was wrong with Thomas' argument. That is why that does not make sense. If you read on you will see that I criticize his position for that reason. > A resource is an abstract thing, reified by representations, right? Something along those lines yes. Henry Story From owner-atom-syntax@mail.imc.org Sat Apr 2 17:15:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00057 for ; Sat, 2 Apr 2005 17:15:10 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32M70EW038733; Sat, 2 Apr 2005 14:07:00 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32M70fX038732; Sat, 2 Apr 2005 14:07:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32M6v5x038724 for ; Sat, 2 Apr 2005 14:06:58 -0800 (PST) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.36.85]) by smtp.cegetel.net (Postfix) with ESMTP id DE2DA377EB; Sun, 3 Apr 2005 00:06:51 +0200 (CEST) Message-ID: <424F1779.6010007@cegetel.net> Date: Sun, 03 Apr 2005 00:06:49 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Henry Story Cc: Atom Syntax , bloged@above.proper.com, atom-owl@googlegroups.com, Eric Scheid Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> In-Reply-To: <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: > On 1 Apr 2005, at 19:52, Thomas Broyer wrote: >> Taking back Eric's example: >> >> ... >> > href="http://example.net/somethingelse.atom" /> >> ... >> >> My interpretation is that "...somethingelse.atom" is the next (entry >> or whatever is defined by the @rel value herein) from the point of >> view of the entry containing the link element. > > > ok. <...somethingelse.atom> would be the next resource. Though I think > the next link was meant for feeds, and has been moved over to the API > document. This is not the same "next" relationship... > So it is a little unfortunate to be basing your argument on an example > that is not in the spec, and that if it were would be attached to the > feed. Well, feeds also carry link elements with a possible "alternate" value for their rel attribute... >> If you replace the @rel with @rel="alternate", then >> "...somethingelse.atom" is an alternate representation of "me" ("me" >> being the entry carrying the link element). > > no. <...omething.else.atom> is a resource, not a representation [1]. > So what you mean to say is that <...somethingelse.atom> is an alternate > resource of me. But that won't do since "me" is a representation. Hence > what we have to say is that "me" is an alternate representation of the > <...somethingelse.atom> resource. Ok, I finally understand what you mean... Actually, the problem is applying "alternate version" to "resource" rather than "representation of a resource". What about: [[ The value "alternate" signifies that the IRI in the value of the href attribute identifies a resource whose representations are an alternate version of the resource described by the containing element. ]] > I really don't see the problem > > "..." ---alternate---> <..else.html> > > think of it as a short hand for > > "..." ---alternate-representation-of---> <..else.html> But the former one says (fmpov) something like "...else.html" is an alternate of "entry" while the latter says "entry" is an alternate (representation) of "...else.html". You are switching the directions of the meanings (ok, without switching the directions of the arrow... that's something like active/passive forms in grammar) > Here we are! > As I said above this is not a causal relationship. We are not saying that > the ... representation is "known" by the hrefed resource, > that it can produce it, or anything like that. We are just saying that it > is an alternative representation (alternative is happily quite vague) of > the remote resource. yes >> whichever is the "primary" representation... Well, in a few words: >> they are alternate representations of the same thing. > > "They" meaning what? > <...else.html> and "..." are not both representations > only the second one is. The problem with the web-arch "language" is that once you print a web page (a representation of a resource), it (the printed sheets) is not the same resource any more (if I understand correctly). Though the still are resources/representations/call-how-you-want of the same "thing". > what you mean is that <...else.html> has many representations. Some of > these are html > ones that it produces, others are atom ones that are produced by others. > We have something > like this > > <...else.html> ---representation---> "..." > |-----------representation---> "..." > | > |-----------representation---> "..." > > > If we now distinguish between cause and uncaused ones (call crep and rep) > > <...else.html> ---crep---> "..." > |-----------crep---> "..." > | ^ > | | > | similar > | | > |-----------rep---> "..." > > now "similar" is indeed a bi-directional representation. And I think you > are speaking of the similar relation just illustrated. Yes, but why not call it "alternate"? -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sat Apr 2 18:05:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02579 for ; Sat, 2 Apr 2005 18:05:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32Mvp6J040974; Sat, 2 Apr 2005 14:57:51 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j32MvpWf040973; Sat, 2 Apr 2005 14:57:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from home.fastolfe.net (postfix@adsl-65-71-209-3.dsl.stlsmo.swbell.net [65.71.209.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j32MvoIw040962 for ; Sat, 2 Apr 2005 14:57:51 -0800 (PST) (envelope-from fastolfe@fastolfe.net) Received: by home.fastolfe.net (Postfix, from userid 1001) id D64BA16EDD; Sat, 2 Apr 2005 16:57:48 -0600 (CST) Date: Sat, 2 Apr 2005 16:57:48 -0600 From: David Nesting To: Atom Syntax Subject: Re: Why is alternate link a MUST? Message-ID: <20050402225748.GM30546@home.fastolfe.net> References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42416CE1.3010609@labs.mot.com> User-Agent: Mutt/1.4i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Why isn't this requirement a "may" instead of a "must"? I can see having > a link with rel=alternate if indeed a alternate version does exist. It > does not make sense to put in some something misleading if an alternate > does not exist. I recently sought out and joined this list precisely because I wanted to see if this issue had been addressed. I don't think it's reasonable to assume there will always be an alternate version of a feed. If this remains a "MUST", I have no choice but to honor this by using a dummy value for an "alternate" page, since I may not have an alternate. Without any background, it seems to me that the goal here is to "require" a link *back* to an HTML page that is presumed to have provided an "alternate" link to this Atom resource. This of course assumes that an HTML or non-Atom version actually exists, and that resource is independent of the Atom resource. (Consider that I may have an HTML version, but it could be derived from the Atom version using XSLT. It's not accurate to consider this an "alternate" when it's an XML style sheet involved.) I couldn't find any reference to this issue in the mailing list, aside from this (thankfully recent) thread. If it's been addressed before, could someone point me to the thread in the list archives? David -- == David Nesting WL7RO Fastolfe david@fastolfe.net http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01 From owner-atom-syntax@mail.imc.org Sat Apr 2 21:31:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13117 for ; Sat, 2 Apr 2005 21:31:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j332N2fv050962; Sat, 2 Apr 2005 18:23:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j332N2xd050961; Sat, 2 Apr 2005 18:23:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j332MxCo050951 for ; Sat, 2 Apr 2005 18:22:59 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j332OHYf024129; Sat, 2 Apr 2005 21:24:26 -0500 Message-ID: <424F5379.8010508@intertwingly.net> Date: Sat, 02 Apr 2005 21:22:49 -0500 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Nesting CC: Atom Syntax Subject: Re: Why is alternate link a MUST? References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> In-Reply-To: <20050402225748.GM30546@home.fastolfe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Nesting wrote: >>Why isn't this requirement a "may" instead of a "must"? I can see having >>a link with rel=alternate if indeed a alternate version does exist. It >>does not make sense to put in some something misleading if an alternate >>does not exist. > > > I recently sought out and joined this list precisely because I wanted > to see if this issue had been addressed. I don't think it's reasonable > to assume there will always be an alternate version of a feed. If this > remains a "MUST", I have no choice but to honor this by using a dummy > value for an "alternate" page, since I may not have an alternate. > > Without any background, it seems to me that the goal here is to "require" > a link *back* to an HTML page that is presumed to have provided an > "alternate" link to this Atom resource. This of course assumes that an > HTML or non-Atom version actually exists, and that resource is independent > of the Atom resource. (Consider that I may have an HTML version, but > it could be derived from the Atom version using XSLT. It's not accurate > to consider this an "alternate" when it's an XML style sheet involved.) > > I couldn't find any reference to this issue in the mailing list, aside > from this (thankfully recent) thread. If it's been addressed before, > could someone point me to the thread in the list archives? I can point you to the threads (yes, this has come up mutiple times). Do you, today, produce an RSS feed? If so, what version of RSS? Is it valid? I've run a feedvalidator for years. Every version of RSS has required this link. I've *never* heard anybody complain about this in the context of any version of RSS. It puzzles the bejeebers out of me why this issue is only brought up in the context of Atom. - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Apr 3 08:46:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20482 for ; Sun, 3 Apr 2005 08:46:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33CbLpv008443; Sun, 3 Apr 2005 05:37:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33CbL5c008442; Sun, 3 Apr 2005 05:37:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33CbJ26008396 for ; Sun, 3 Apr 2005 05:37:20 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j33CbD714125; Sun, 3 Apr 2005 21:37:13 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 33852a1e_a43e_11d9_9f91_0030482532aa_9433; Sun, 03 Apr 2005 21:45:04 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO000D7C; 3 Apr 05 21:37:56 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 3 Apr 05 21:37:29 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.250.1) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG000D79; 3 Apr 05 21:37:28 +0900 Message-Id: <6.0.0.20.2.20050403101341.02fb0b20@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 03 Apr 2005 10:14:33 +0900 To: David Nesting , Atom Syntax From: Martin Duerst Subject: Re: Why is alternate link a MUST? In-Reply-To: <20050402225748.GM30546@home.fastolfe.net> References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Of course I'm also for making an alternate link for a feed a MAY rather than a MUST. Regards, Martin. At 07:57 05/04/03, David Nesting wrote: > >> Why isn't this requirement a "may" instead of a "must"? I can see having >> a link with rel=alternate if indeed a alternate version does exist. It >> does not make sense to put in some something misleading if an alternate >> does not exist. > >I recently sought out and joined this list precisely because I wanted >to see if this issue had been addressed. I don't think it's reasonable >to assume there will always be an alternate version of a feed. If this >remains a "MUST", I have no choice but to honor this by using a dummy >value for an "alternate" page, since I may not have an alternate. > >Without any background, it seems to me that the goal here is to "require" >a link *back* to an HTML page that is presumed to have provided an >"alternate" link to this Atom resource. This of course assumes that an >HTML or non-Atom version actually exists, and that resource is independent >of the Atom resource. (Consider that I may have an HTML version, but >it could be derived from the Atom version using XSLT. It's not accurate >to consider this an "alternate" when it's an XML style sheet involved.) > >I couldn't find any reference to this issue in the mailing list, aside >from this (thankfully recent) thread. If it's been addressed before, >could someone point me to the thread in the list archives? > >David > >-- > == David Nesting WL7RO Fastolfe david@fastolfe.net http://fastolfe.net/ == > fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01 From owner-atom-syntax@mail.imc.org Sun Apr 3 09:08:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21874 for ; Sun, 3 Apr 2005 09:08:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33CwvNU015469; Sun, 3 Apr 2005 05:58:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33Cwvva015468; Sun, 3 Apr 2005 05:58:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from faceman.dreamhost.com (postfix@faceman.dreamhost.com [205.196.210.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Cwrtn015436 for ; Sun, 3 Apr 2005 05:58:54 -0700 (PDT) (envelope-from arve@virtuelvis.com) Received: from wintermute (ti132110a080-0138.bb.online.no [85.165.128.138]) by faceman.dreamhost.com (Postfix) with ESMTP id 289BD111D8A; Sun, 3 Apr 2005 05:58:51 -0700 (PDT) Date: Sun, 03 Apr 2005 14:57:29 +0200 To: Atom-syntax Subject: Re: Why is alternate link a MUST? Cc: "Martin Duerst" , "David Nesting" References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <6.0.0.20.2.20050403101341.02fb0b20@itmail.it.aoyama.ac.jp> From: "Arve Bersvendsen" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <6.0.0.20.2.20050403101341.02fb0b20@itmail.it.aoyama.ac.jp> User-Agent: Opera M2(BETA3)/8.0 (Win32, build 7537) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit n Sun, 03 Apr 2005 03:14:33 +0200, Martin Duerst wrote: > Of course I'm also for making an alternate link for a feed a > MAY rather than a MUST. +1 I don't see any advantage at all in forcing an alternative representation to exist, and I have yet to see a real argument[1] why such an alternative representation must exist . ___ [1] "simplifies validation", and "causes problems for some newsreaders" are not arguments. -- Arve Bersvendsen - http://virtuelvis.com/ From owner-atom-syntax@mail.imc.org Sun Apr 3 09:54:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25062 for ; Sun, 3 Apr 2005 09:54:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Dk1Hr031466; Sun, 3 Apr 2005 06:46:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33Dk1Tc031465; Sun, 3 Apr 2005 06:46:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Dk0Xr031457 for ; Sun, 3 Apr 2005 06:46:00 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1DI5QN-0001u4-00; Sun, 03 Apr 2005 14:45:59 +0100 Date: Sun, 3 Apr 2005 14:45:59 +0100 From: James Aylett To: Atom Syntax Subject: Re: Why is alternate link a MUST? Message-ID: <20050403134559.GY6334@tartarus.org> Mail-Followup-To: James Aylett , Atom Syntax References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424F5379.8010508@intertwingly.net> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Apr 02, 2005 at 09:22:49PM -0500, Sam Ruby wrote: > I've run a feedvalidator for years. Every version of RSS has required > this link. I've *never* heard anybody complain about this in the > context of any version of RSS. It puzzles the bejeebers out of me why > this issue is only brought up in the context of Atom. Speaking personally, I would never have complained about it in the context of RSS because RSS is such a fragmented mess. It comes up in the context of Atom because Atom is trying to be unambiguous and helpful. If MUST is vastly preferable for user agent implementors, then IMHO there should at least be an explanation of what to do when you can't generate an alternate repr (for instance: you may not have enough resource to build an alternate version when you know that alternate version won't be used). Given that the spec currently deliberately backs off on implementation usage (and rightly so), but marks round tripping as a SHOULD (but puts these in different sections with no cross-linking), I feel that a tiny bit (not sarcastic - literally a tiny bit) more guidance for feed producers would be helpful. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Sun Apr 3 11:46:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03979 for ; Sun, 3 Apr 2005 11:46:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Fb9VN037780; Sun, 3 Apr 2005 08:37:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33Fb9B2037779; Sun, 3 Apr 2005 08:37:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j33Fb71N037769 for ; Sun, 3 Apr 2005 08:37:08 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 03 Apr 2005 15:37:00 -0000 Received: from xdsl-213-196-246-73.netcologne.de (EHLO klangraum) [213.196.246.73] by mail.gmx.net (mp010) with SMTP; 03 Apr 2005 17:37:00 +0200 X-Authenticated: #163624 Date: Sun, 3 Apr 2005 17:37:08 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Why is alternate link a MUST? Message-ID: <20050403153708.GA6068@klangraum> Mail-Followup-To: Atom Syntax References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <424F5379.8010508@intertwingly.net> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Sam Ruby [2005-04-03 04:30]: > Every version of RSS has required this link. I've *never* > heard anybody complain about this in the context of any version > of RSS. It puzzles the bejeebers out of me why this issue is > only brought up in the context of Atom. My guess is that it’s because Atom actually tries to define a content model that allows more than just title, link, description. Multiple links and payloads with different semantics each are supported and, if that’s what appropriate for a particular case, encouraged. So I think it’s no wonder that people are seeing Atom as a transport for things they might have either not done with RSS, or inclued fudged links for. Examples that suggest a need for MAY certainly exist: I have one. I run a scraped feed[1] for the Slackware news, where the content from a single web page is scraped divided into multiple separate entries. [1] http://plasmasturm.org/feeds/ These don’t appear individually on pages of their own, so it would be most logical to omit the alternate representation link entirely. An alternate representation MUST be given, however, so I use the same link as an for each entry as I use for the feed itself. Cruft. Regards, -- Aristotle “If you can't laugh at yourself, you don't take life seriously enough.†From owner-atom-syntax@mail.imc.org Sun Apr 3 13:17:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10833 for ; Sun, 3 Apr 2005 13:17:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33H5UE3044979; Sun, 3 Apr 2005 10:05:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33H5UBv044978; Sun, 3 Apr 2005 10:05:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33H5JMx044964 for ; Sun, 3 Apr 2005 10:05:19 -0700 (PDT) (envelope-from lindsley@labs.mot.com) Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j33HA7Qv027335 for ; Sun, 3 Apr 2005 10:10:11 -0700 (MST) Received: from labs.mot.com (udomsvc1.labs.mot.com [173.23.250.1]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j33H6LsS027963 for ; Sun, 3 Apr 2005 12:06:22 -0500 (CDT) Received: from ims1.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j33H58RG016917; Sun, 3 Apr 2005 12:05:08 -0500 (CDT) Received: from [192.172.32.205] by udomsvc5.labs.mot.com (mshttpd); Sun, 03 Apr 2005 12:05:08 -0500 From: Brett Lindsley To: Sam Ruby Cc: David Nesting , Atom Syntax Message-ID: <54e33e44.3e4454e3@ims1.labs.mot.com> Date: Sun, 03 Apr 2005 12:05:08 -0500 X-Mailer: iPlanet Messenger Express 5.2 (built Feb 21 2002) MIME-Version: 1.0 Content-Language: en Subject: Re: Why is alternate link a MUST? X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit There's been a lot of interesting follow-on as to why this issue has been revisited in Atom. One additional issue I was looking at was forming a feed created by a serach operation. Consider a feed returned as a result of a search operation (e.g. a time range). To create an alternate representation of this resource, the link must also specify the same conditions that resulted in the search results. That is, the alternate link needs to somehow embed the search conditions of the search that created the feed so the server can provide an alternate representation. One way to fix this would be to indicate in the protocol spec that the same http headers must be provided to the alternate link as those used to request the feed. One practical issue is when a home page or something is used as the link when there is no meaningful alternate representation. In this case, a user may see a alternate representation link and click on it. Getting a home page when the link should be an alternate representation of the feed may be considered to be a product failure. The typical thing to do from a product design point of view is to always ignore the alternate link. From a practical point of view, there is no way for the client (or a validator) to determine if the representation returned in the alternate link is actually an alternate representation of the feed. Brett Lindsley, Motorola Labs ----- Original Message ----- From: Sam Ruby Date: Saturday, April 2, 2005 7:22 pm Subject: Re: Why is alternate link a MUST? > > David Nesting wrote: > >>Why isn't this requirement a "may" instead of a "must"? I can > see having > >>a link with rel=alternate if indeed a alternate version does > exist. It > >>does not make sense to put in some something misleading if an > alternate>>does not exist. > > > > > > I recently sought out and joined this list precisely because I > wanted> to see if this issue had been addressed. I don't think > it's reasonable > > to assume there will always be an alternate version of a feed. > If this > > remains a "MUST", I have no choice but to honor this by using a > dummy> value for an "alternate" page, since I may not have an > alternate.> > > Without any background, it seems to me that the goal here is to > "require"> a link *back* to an HTML page that is presumed to have > provided an > > "alternate" link to this Atom resource. This of course assumes > that an > > HTML or non-Atom version actually exists, and that resource is > independent> of the Atom resource. (Consider that I may have an > HTML version, but > > it could be derived from the Atom version using XSLT. It's not > accurate> to consider this an "alternate" when it's an XML style > sheet involved.) > > > > I couldn't find any reference to this issue in the mailing list, > aside> from this (thankfully recent) thread. If it's been > addressed before, > > could someone point me to the thread in the list archives? > > I can point you to the threads (yes, this has come up mutiple times). > > Do you, today, produce an RSS feed? If so, what version of RSS? > Is it > valid? > > I've run a feedvalidator for years. Every version of RSS has > required > this link. I've *never* heard anybody complain about this in the > context of any version of RSS. It puzzles the bejeebers out of me > why > this issue is only brought up in the context of Atom. > > - Sam Ruby > > From owner-atom-syntax@mail.imc.org Sun Apr 3 13:35:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12119 for ; Sun, 3 Apr 2005 13:35:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33HRh01046348; Sun, 3 Apr 2005 10:27:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33HRhtu046347; Sun, 3 Apr 2005 10:27:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from home.fastolfe.net (postfix@adsl-65-71-209-3.dsl.stlsmo.swbell.net [65.71.209.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33HRhq4046341 for ; Sun, 3 Apr 2005 10:27:43 -0700 (PDT) (envelope-from fastolfe@fastolfe.net) Received: by home.fastolfe.net (Postfix, from userid 1001) id 4399D16EDD; Sun, 3 Apr 2005 12:27:40 -0500 (CDT) Date: Sun, 3 Apr 2005 12:27:40 -0500 From: David Nesting To: Atom Syntax Subject: Re: Why is alternate link a MUST? Message-ID: <20050403172739.GN30546@home.fastolfe.net> References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050403134559.GY6334@tartarus.org> User-Agent: Mutt/1.4i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Apr 03, 2005 at 02:45:59PM +0100, James Aylett wrote: > > Speaking personally, I would never have complained about it in the > context of RSS because RSS is such a fragmented mess. It comes up in > the context of Atom because Atom is trying to be unambiguous and > helpful. This is my view as well. > If MUST is vastly preferable for user agent implementors, then IMHO > there should at least be an explanation of what to do when you can't > generate an alternate repr I was able to locate a previous thread where this issue was discussed, but the thread appeared to peter out before this question was asked/answered. Consider for a minute these two scenarios where one might want to use Atom: 1. Where the Atom resource is the only HTTP resource representing that list of syndicated content. I MAY have an HTML version that is derived from the Atom one using XML style sheets, but I might not. That's my call. 2. Where the Atom resource itself isn't even delivered by HTTP. I may place it in a message delivered via SMTP, or in my own application protocol. Maybe I'm multicasting it to an application in my organization. I may be referencing content that *is* accessible on the web, but my actual syndication list isn't. At a minimum we need to specify what implementers must do when no alternate version exists. Even if that means specifying "about:blank" as the alternate URL, it should at least be documented. That way, implementations that choose to do so can at least make an educated decision about whether the value of that alternate link is meaningful or just a dummy value. If we can't or don't want to document this in the specification, maybe all we need is some unofficial, non-binding agreement now that implementations can CHOOSE to follow if they want. Maybe someone can whip up a persistent URI that can either stand for (or even deliver a message saying) "no alternate exists"? I suggested about:blank earlier, but maybe something delivered via HTTP (a la http://www.example.com/) might be appropriate? Maybe "x-atom:no-alternate-uri"? Implementations that abide solely by the specification and aren't aware or choose not to follow this convention only run the risk of allowing users to follow broken or useless links, which is exactly the situation we have today anyway. I've used RSS in some unofficial capacity in some internal applications. Maybe the regurgitated specifications I had my hands on were just incomplete or inaccurate, but none of these had any "alternate" link requirement. Many of my own feeds would have had "alternate" links with dummy values if I had been more aware of this requirement. So just because nobody complained about the artificial constraint in RSS doesn't mean the constraint is legitimate. I've found that every RSS reader or RSS "consumer" application handled these feeds without a problem. I should point out that the reason I am interested in Atom is to take this to the "next level" in my organization and actually back an IETF standard syndication format for these purposes. The RSS implementations have just been proofs of concept at this point. Thanks for your time. David -- == David Nesting WL7RO Fastolfe david@fastolfe.net http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01 From owner-atom-syntax@mail.imc.org Sun Apr 3 14:00:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14700 for ; Sun, 3 Apr 2005 14:00:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33HpPXA047473; Sun, 3 Apr 2005 10:51:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33HpPfs047472; Sun, 3 Apr 2005 10:51:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33HpOro047458 for ; Sun, 3 Apr 2005 10:51:25 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j33HpOX8022349 for ; Sun, 3 Apr 2005 11:51:24 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IED005GXTLON9@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 03 Apr 2005 11:51:24 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IED00HTATLNJS@mail.sun.net> for atom-syntax@imc.org; Sun, 03 Apr 2005 11:51:24 -0600 (MDT) Date: Sun, 03 Apr 2005 10:51:50 -0700 From: Tim Bray Subject: Re: Why is alternate link a MUST? In-reply-to: <20050403172739.GN30546@home.fastolfe.net> To: David Nesting Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT OK, I observe a lot of people speaking up for -less feeds, presenting some plausible use cases. I observe only Sam speaking up for retaining the compulsory link. I observe at least one person speaking up saying "if it's compulsory I'll generate a fake one", which seems significant to me. I'm starting to smell possible consensus; are there more people here who agree with Sam? If so, speak up. Also, if dropping is going to break something (haven't heard that yet), someone should please point that out. Apologies in advance if you already have spoken on this and I missed it. -Tim From owner-atom-syntax@mail.imc.org Sun Apr 3 15:18:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20290 for ; Sun, 3 Apr 2005 15:18:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33J6Urc052596; Sun, 3 Apr 2005 12:06:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33J6Uia052595; Sun, 3 Apr 2005 12:06:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33J6Rqf052588 for ; Sun, 3 Apr 2005 12:06:27 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id f1so1555340rne for ; Sun, 03 Apr 2005 12:06:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=qFom+XXp3m6H/rq+XtMWYvfIyo3xtf0d3WoEgek+rZML1pMehIoxrwfj4M+pDSO3ckA2zEaaud+7AmXU+aJtyuXgObln818jiB2eHuAsANJdnvQsz/Lm0zo4BIWqiKMIQLhkcrnV0wBs/yvefRZRKgTJBO7m9ULI1xWRv0XYvWA= Received: by 10.38.151.1 with SMTP id y1mr4584542rnd; Sun, 03 Apr 2005 12:06:26 -0700 (PDT) Received: by 10.38.151.18 with HTTP; Sun, 3 Apr 2005 12:06:26 -0700 (PDT) Message-ID: <3f1451f5050403120638d8f259@mail.gmail.com> Date: Sun, 3 Apr 2005 15:06:26 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Tim Bray Subject: Re: Why is alternate link a MUST? Cc: David Nesting , Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 3, 2005 1:51 PM, Tim Bray wrote: > > OK, I observe a lot of people speaking up for -less feeds, > presenting some plausible use cases. I observe only Sam speaking up > for retaining the compulsory link. I observe at least one person > speaking up saying "if it's compulsory I'll generate a fake one", which > seems significant to me. > > I'm starting to smell possible consensus; are there more people here > who agree with Sam? If so, speak up. I agree with Sam, +1 to the required . The argument that you can't have an HTML representation are weak, since *I* can generate one for your feed, whether you like it or not, ala: http://www.rss2html.com/ I can also generate an XSLT sheet that transforms Atom into HTML then use the W3C XLST service to transform an Atom feed into HTML: http://www.w3.org/2001/05/xslt Now the generated HTML may not be optimal but I hope this shows that barrier to generating an HTML 'alternate' is not onerous, and that the link should remain a MUST. Thanks, -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sun Apr 3 15:27:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20885 for ; Sun, 3 Apr 2005 15:27:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JLW8t053598; Sun, 3 Apr 2005 12:21:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33JLW6u053597; Sun, 3 Apr 2005 12:21:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JLVhZ053588 for ; Sun, 3 Apr 2005 12:21:31 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 81742 invoked by uid 17064); 3 Apr 2005 19:21:29 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.232.97]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 3 Apr 2005 19:21:29 -0000 In-Reply-To: <424F1779.6010007@cegetel.net> References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/mixed; boundary=Apple-Mail-45--1042582885 Message-Id: Cc: Atom Syntax , atom-owl@googlegroups.com, bloged , Eric Scheid From: Henry Story Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state Date: Sun, 3 Apr 2005 21:21:26 +0200 To: Thomas Broyer X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-45--1042582885 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Let me skip right to the core of your answer. On 3 Apr 2005, at 00:06, Thomas Broyer wrote: > What about: > [[ > The value "alternate" signifies that the IRI in the value of the href > attribute identifies a resource whose representations are an alternate > version of the resource described by the containing element. > ]] The question is here: what is "the resource described by the containing element" referring to? As I argued in a previous post to this thread [1] my belief is that this is the resource named by the id of the entry. I did not make that aspect of my thinking visible in the graph attached to my previous mail [2] so I will now, by adding the representation relations (named "repres") in the following graph: --Apple-Mail-45--1042582885 Content-Type: image/jpeg; x-mac-hide-extension=yes; x-unix-mode=0644; name="Atom-related.jpg" Content-Disposition: inline; filename=Atom-related.jpg Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAFsAjEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKQsB1oAWiozMg70ecnq KAJKKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUUolU9DQA+ikBzS0AFFJSG RR1NADqKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUU4O D0NADqKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigBK5nxpcldBuIwSN5RDg4yC4BH 4iumPSuL8cMf7NYf9NI//Q1pPYDR/wCER0P/AKB0P6/40f8ACIaH/wBA2H9f8a2abLLHBE8szrHG ilmdjgKByST2FedzS7iMj/hEND/6BsP6/wCNH/CIaH/0DYf1/wAaz9a8VSNoV9c6NbXTxxW7yC+M YWMEKSNofl8nHQEe9NvPE+qRyC2XTYYLtLq2R0e43KYpWIByF4OVII7dcmq9/uBpf8Ihof8A0DYf 1/xo/wCEQ0P/AKBsP6/41nx+Lr+4uIYrbRN4uZJ4oGa6ChmiYhi3ynaDg4PJzxjvRYeKLq9uZLmC yuLm0eztZxBHs8yLzPNLHkjd91RjPbij3+4Gh/wiGh/9A2H9f8aP+EQ0P/oGw/r/AI1d07VrPVUk NpKWaIhZY3UpJGfRlYAr+Iq5U80u4GN/wiGh/wDQNh/X/GszxH4f0vTNDnvLOzSG4hKMkiEgqd68 jmusrD8a/wDIpX/+6v8A6GtVGT5lqBu2c/nIDVqsnRWzAufStavQGRzPsQmuHns7XWvFmoi9iEyw 28AQMThcmXOPrgflXaXpxAa4vSDnxVrOf+eNv/OWsqztB2E9ix/wi2jf8+EX5n/Gj/hFtG/58Ivz P+Na1Ub/AFi0050imZ3uJATHBEheRwO4Uc49zx71xc0n1M9Sv/wi2jf8+EX5n/Gj/hFtG/58IvzP +NZd14l1O01C7kbTJPs8Fil08EkyK0ah5NxyM5Yqo+XOOOoqQeJL+O+u4fsMc4OoJaWoSbbwYBLl sr07/wDAiOcc17/cepof8Ito3/PhF+Z/xo/4RbRv+fCL8z/jWRP4uu5NKuZRYGzZra6MEplVyJYQ d2VxjGQcHvjkCtX/AISGOzONVgms4+Nty4BhcdiXHCf8CxS9/uGo7/hFtG/58IvzP+NH/CLaN/z4 Rfmf8a1qKnml3Fcyf+EW0b/nwi/M/wCNJoCQ6X4m1K0tU8uAwW7iME4DEyZP1OB+QrXrCt2I8cXo /wCnW3/9ClrahJuerKjudyh3KDTqjg5iFSV2lhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFcUPiJ/olnLLY29tJeRG4iS7 v0iBiGOdxH3iSQq9wMkiu1rl30XT7W403TrPVLy1vra1MCGAK8jQcffBQhRlRhsDnp6UAMfxs0kU l1Zaa09jBZw300zTBCsUgZuFwcsApOMj60XnjcWaXcktkkcEV39ihmluVjSWXr1I+VQuSWPpgA06 bwg15qd8Jry7j0+e1gtmjWRWNwqbwwcsC3cDIIJyea0J/DVtLbSRpPcRSNdm9jmQruil9VyCMYyM EHgmgDIb4gQtZQSQQWryySywsWvVWDem07VlwQxYMCoOM85xiutifzIkcqVLKDtOMj24rGm8Mme0 SF9W1Ek+YJnZo384PjIKspUYwMYAxz6nOta20dnaQ20IIihRY0BOTgDA5/CgCasia58QLPILfS9L eIMQjSajIjMueCQIDg+2T9a16KAMX7X4k/6BGk/hqkn/AMYo+1+JD00jSh9dTk/+MVtUUAeXfE4e MZLDTpbCNreYXBRU0u6lkdiyk/N8i8fKetZv2PxbBojSeKb6KTLRhINil0O9eWdePXjnr1r2I9K5 Txdp8t9p8scDKknDIzLkZBBGR6cUMDoaRlV1KuAysMEEZBFcFP4u8SQsR9k01v8AgMn+NRf8Jr4k /wCfLTvyk/xrh9hMR09x4R0+WCaC3e4s7edGSWC3kxEwYEcIQVU85yoHTnPSp77w9b313NcmaeKa QwHchX5DCzMpAIPdjnOfwrkf+E18Sf8APlp35Sf40f8ACa+JP+fLTvyk/wAafsqgzsLbQLa1ktHj eYm1kmkTcRyZWLNnj1Jx/Wqlt4RtbSFYYLy/jjEMUDBJQhdI920FlAIzvOcEdB05zzX/AAmviT/n y078pP8AGj/hNfEn/Plp35Sf40eyqAdra6Pa6f5QsE+yxo5d0iAAmJBHzkjJ65znOR1qW2s3tzGW vLmfZEIyJSvznP3zhR83049q4X/hNfEn/Plp35Sf40f8Jr4k/wCfLTvyk/xo9jMD0OsPxr/yKN// ALq/+hrXMf8ACa+JP+fLTvyk/wAaLnVdf8Q2L2NxFYQwzFQ7IjlgAwJxk9eKI0Zppgdvon+oX6Vr 1m6TGY4VB9K0q7QK17/qDXF6P/yNWs/9cbf+ctdtdruhIrz7UV1TSdZu7zTxbOtxHGrLMrZBQt0I P+1+lZ1YuUWkJ7HVVUvtLs9SC/a4Fdk+5IMq6e6sOV/A1yR8U+IgcfZNP/J/8aP+Eq8Rf8+mn/k/ +NcvsJkcrOh/4R2BorxJbq7l+12v2R2kcFgmXxg46/OeTnoKcnh63S/+1CafP2hLkR5XbvWIxZ6Z 5XGRnqB05zzn/CVeIv8An00/8n/xo/4SrxF/z6af+T/40/Y1B2ZvzeF7OazW2aS4CAXAyGGf327f 27bjj+tTf8I/ZyT+beeZeMpyi3Dbkj9NqfdGPXGfeua/4SrxF/z6af8Ak/8AjR/wlXiL/n00/wDJ /wDGj2NQLM64WbhgftlycM7YJXB3dB93ovb9c1PDGYYI42keUooUu+NzYHU4AGT9K4r/AISrxF/z 6af+T/40f8JV4i/59NP/ACf/ABpewmLlZ3Fcfq+sDQvE1/etZ3V0iW1vuS2QMyjMvzEEjjjrUCeJ /ETtj7Lp4/B/8a1vD9vfXOrz6hf+SJJY44wkKkABSxzyf9r9K0pUpRldlJNMzPD3xotdX1+DT5LB LGzYMZLu4uQAgCkjIxgZIA6969ItNTsb9c2V5bXAPeGVX/kaz7HwrpFlrbaza2UcN9JGY3eP5QwJ BJK9M8detWbvw/pF+2680uxnb1kt0Y/mRXUUaNFYv/CJaUv/AB7pdWvp9mvJogPwVgKP+Eenj/49 te1aH2Lxyj/yIjGgDaorF/s/Xov9TrkEn/XzYhv/AEB0o3eJYv4NIuf+BywZ/R6ANqis6wu9TmnM d/psVsoXIkiuRKpPpyqn9O1VLrxZZWl5fW8kN2TY7FldYsqXcLsRTnlmLgAevXHGQDcorn28YWqm OI2N/wDbHnNv9jEa+aH2eZg/NtwV5znHvSp4xsHlgjEV3mWJ5nzHgQKjFXMhz8u1gQf0zQBv0Vz6 +MrH7NJLPb3lviNJY0mjCtMjsEUrzjliB82CMjOK1tOvv7QtfNNtcWzBijRToFdSPoSD9QSKALVF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUVQ1jUxpdkHSPzrmVx Fbwg4Msh6DPYdST2AJ7UAV9X1O4FwumaSEfUZV3l3GUto848x/XvtX+IjsASLOl6TBpMDJFuklkO +aeQ5kmf+8x/p0A4AApmjaWdNt3aeQT3tw3m3U+Mb39B6KBwB2A9cmtGgAooooAKKKKACiiigAoo ooAKrXFsJhgirNFAGJJocbnO0Uz/AIR+P+4PyreooAwf+Efj/uD8qP8AhH4/7g/Kt6igDB/4R+P+ 4Pyo/wCEfj/uD8q3qKAMH/hH4/7g/Kj/AIR+P+4PyreooAwf+Efj/uD8qng0eOIghRWvRQBHFEI1 wKkoooAay7his+50xJzytaVFAGCdAjJ+6KP+Efj/ALg/Kt6igDB/4R+P+4Pyo/4R+P8AuD8q3qKA MH/hH4/7g/Kj/hH4/wC4PyreooAwf+Efj/uD8qP+Efj/ALg/Kt6igDCXQYwc7RV+209YOgq9RQAg GBS0UUAFFFFABRRRQAVz+p+FI9TttViknQ/b7iK5UPCHWNo1jADKT86kx8jjIJHvXQUUAcX/AMIt fadeaY+nHT4ZhdyTSNb2AjgjXyWUAorBjn1LZyfTitC08Hxwxzpc3bTi6tZoLghNpdpZGd2HJxy5 AHOOOa6SigDkbLwQ9nZ3EaSaSkrwrCpi0pFR1DAnzQSS+7GCAQO455G14f0c6Hp7W3mIwaRpAkaF I4gcfKiknCjHTPc9OlalFAFPULyeyjSSGwnvATh1gZNyj1wxGfwOfaoLLxFp19cC2Wcw3Z/5drlD DL+CsASPcZFadVr7T7TU7cwX1tFcRHnbIoYA+o9D70AWaK57Nx4ZuoVeeW50eZ1iDTMXktHYgJ8x 5ZCTjnJUkckfd6GgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigBKwtIH9t6k2t yc2yBodPXtsz80v1cjj/AGQP7xp3iCR76WDQ7Zysl4C1w6nBitx9857FshB9Sf4a2Yo0hiSOJFSN FCqqjAAHQCgB9FFFABWFrN1fjxDpVnZXPkQyxTzTgRh2cRmPCjPTO4j6E98Y0NS1e00mNGupCHkO 2KJFLySt6Ko5J+lNsHmvWW6vNNW1kUFYfMdXlVTjIOBhc4HAY9BQBwieLfEA0JtScmMXOnSXaeeL cJEw2lfLCuXZRuwdwz06dK1L3U9YtNQfSoNVWaVpbTF09un7sSmQMu0YBx5YYd+eSe+9eeFtMuLK /gt7S3tXvkKTTQwqGbJyc8c881bttG02yjEdrp9pCgkEoWOFVG8dG4HX3oA5S21/Wn1ok+a1pHqJ sWEn2dImVflLZLCTzD97AGMcAd6v+FdV1C6vWh1S4dpZbcTomyMxMM4LwyIfmQ5HDfNyK3f7I0/+ 0v7R+w2323GPtHlL5nTH3sZ6cUWWkafpryPY2NtbNIcuYolUt35x7k/nQBbzjrS1FcW0N3byQXMS SwyLtdHXKsPQisn/AIR2Sz50bU7qzx0hkP2iH/vlzkD2VloA26a8ixqWdgABkk9q8z+JXjHxJ4U0 2xCmyiuJLjcJoGLCVFB3KY3X5RyvIY/WqkXj2Xxd4VuIL/SZ7WVggdzGTBKN6ggE+ufunPHc0Aen HVLIf8vUP/fwUn9q2X/P1D/32Kzv+Eb0X/oEaf8A+Ayf4Uf8I3ov/QH0/wD8Bk/wrm+srsBo/wBq 2X/P1D/32KP7Vsv+fqH/AL7FZ3/CN6L/ANAfT/8AwGT/AAo/4RvRf+gPp/8A4DJ/hR9ZXYDR/tWy /wCfqH/vsUf2rZf8/UP/AH2Kzv8AhG9F/wCgPp//AIDJ/hR/wjei/wDQH0//AMBk/wAKPrK7AaP9 q2X/AD9Q/wDfYo/tWy/5+of++xWd/wAI3ov/AEB9P/8AAZP8KP8AhG9F/wCgPp//AIDJ/hR9ZXYD R/tWy/5+of8AvsU5NRtJGCrcREk4ADjmsz/hG9F/6A+n/wDgMn+FZHirRNKtPDtzPb6ZZRSxlGV0 t0VlIdeQQOKaxCbtYDswQelLVSxn86MGrddACVDNeW8BAlmjQnnDMBT532Rk1w5tLPVfF+qNeWlv cGO2t1Uyxq+3mXpkVM5csbibsdh/atl/z9Q/99ij+1bL/n6h/wC+xXO/8I/pH/QKsP8AwHT/AAo/ 4R/SP+gVYf8AgOn+FYfWV2FzHRf2rZf8/UP/AH2KP7Vsv+fqH/vsVzv/AAj+kf8AQKsP/AdP8KP+ Ef0j/oFWH/gOn+FH1ldg5jov7Vsv+fqH/vsUf2rZf8/UP/fYrnf+Ef0j/oFWH/gOn+FH/CP6R/0C rD/wHT/Cj6yuwcx0X9q2X/P1D/32KP7Vsv8An6h/77Fc7/wj+kf9Aqw/8B0/wo/4R/SP+gVYf+A6 f4UfWV2DmOi/tWy/5+of++xU8NzDOCYpEcDglSDXLf8ACP6R/wBAqw/8B0/wrFbWtI8E63qlxOkd rbPBbAJBFje/77gAdyB39KuFZTdrApXPSKK8o8O/GG58QeMRYQaS7WbxOIYYypndxzklmVQMA8fq a7z7T4hu/wDU2NlYIf47mYzOP+AJgf8Aj9bFG3Uc7FLeRl6qpI/Ksj+wbq651PWr6YHrFbEWyfgU +f8A8fNaNlp1rp9r9ntYgkRJJBJYsT1JJyT+NAHERa34hktNIh+0zyz3mnnUJJbaG3BXhAEAkZRt G4lj1ORjaKePEesS2t7qMl9FB9igtJjZxJHIsrSIpZd/OQSSFKnr3IrsLrRNMvreC3u9OtJobcAQ xyQqyxgDGFGOBjjiqyeGtO/tibUprWCad2Ro2kiUmHaoUbTjI6ZoA5u41vXEjylxJL9s1aaxhWCG IPDHGZTkFyFLnYB8xxjsT1bPr2u/2dG7SvF5AuDO9uLeWYBHAR5IwxG0DIcIc7hxiuyn0uwubR7W eyt5LeRzI8TRgqzE7ixHrnnPrzUMvh/SJ4LeGXTLJ4rYEQo0ClYweoUY4FAF6GQTQpIrBldQwI6E Gn1n6vqMmk2q3f2czW0bZuCp+aKPu4GPmx1I64yRnGDeR1kRXRgysMgg5BFADqKKKACiiigDE8Y4 PhLUox/rJovJi/66OQqf+PFa26wZm/tvxFHAnNlpbiSZu0lxj5E/4ADuPuU9DW9QAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABUN3dQ2NpNdXMgjghQvI56KoGSamrAvT/AG7raacnzWNi 6zXh7SS8NHF744dv+ADuaAJ/D9rMY59Uvoyl7fkOyN1hjH+rj/AEk/7TNWxRVHU9YtdKRPtDM00p xDBEu+WU+iqOT9eg7kUAXSQBk8CsJ9ZudXdoPDyo0YO2TUJRmFPXYP8Alo30wo7ntSf2Xe66d+u4 hs+q6bG+Q3/XZh97/dHy+u6t1EWNFSNQqKMKqjAA9BQBn6boltpsj3GZLm9kGJbuc7pHHpnoq/7K gD2rSoooAKKKKACiiigAooooAZJFHIVZ0VihypIzg+1cZ44J/s5v+ukf/oa12p6GuK8cf8g5v+us f/oa0nsB1dZet+ILbQltxOkkkty5SGNcLub0LMQq/iRntmtSmSxRzxNFNGskbDDI4yCPcV5q8xHL 6v4k1fRltWu7OxU30ht7eNZyTHK2PLLscZX727A44wTmootW1ez1O/dnt5bIarFaFX3lx5iRLlOc KoZgcc5yenfY/wCET0bZIn2JTG8bxeWXYoitjcEXOEztH3cdKtDRbERsnkkh7hLlsyMSZE27WyTn jYv1xz1NXzRA5Oz8Qa+mnxIHsZ5vIu7p5ZY3HEUoUKAG75PPYY645lm1/VLgQw3PkwSSSafcxm3L DCSzbTGxz833cEjAIJ4ro4fD2mwF/LgYb0ljIMrkBZGDOACeASAeOnbFK+gadI6M1v8AMiRIpEjD AiYtH37Ek+/fNHNHsBSi8SPaanb6ZrNssF3cHbC1vIJY5Pw4dfxXA9a3qpWWj2GnRSJaWyReZ/rH GS7+7OfmJ9yc0HSLQxeXifb5SQ/8fEmdqHK87s555PU9yal2Au1h+Nf+RSv/APdX/wBDWtysPxr/ AMijf/7q/wDoa0Q+JAaOinMC/StasjRP9Qv0rXr0hla9OIDXGaQc+KtZ/wCuNv8Azlrs73/UGuL0 f/katZ/642/85ayr/AxS2N+sODxBJqt1LBo9ujrBJsmmuJNgQg84QfOT9Qo963Kp3elWV9Mk1xbq Zo/uSqSsi/Rhgge2a4VbqZnLT+I9R1HTL1YlhhnsbmC2kMchG+bz1BwQciMr68/MR2Obbarq76vZ Wck1qjxan9nnMcbbZkNs0o4LZHcd+QD0yDrp4b0uNUVLUKEREGHYZCOHXPPJDDOTk8n1OZZNHspb jz2ibzfPW53rIwPmKmwHg/3eCOhGc9armj2Gc1D4k16e1t5Vi01ftFg98uQ52hNuVPPJO4c9uetX LLVdRluNRuraFLiASxs0Mk+xkUwRN8hI29SSQcDnrWxHolhFFFGkGEitmtUG9uIjjK9f9kc9eKjP hzS2I32iuuQxR2ZkJCqoJUnBwFUDI7e5o5o9gJNH1m21yzNzab9quY2DDow6jIyD16gke9X6ry2U EzKWVhsjaNQjsoCtjPAIHYYPUdsU6C0it5GePfuZFQ7pGbhc44J68nnqe+ah2ETVgw8+N70HkG1g yP8AgUtb1YMP/I83v/Xrb/8AoUlbYf4yo7nT2nh/SIryO/i0yzjvEztnSBVcZGDyBnoSPxrVqKD/ AFQqWu4sKKKKACiiigAooooAQgEEEZB6isPQs6VfXGhOT5US+fZE/wDPAnBT/gDcf7pSt2sbxHby rbwanaIz3WnP5wReskZGJEH1XkD+8q0AbNFRW9xFd20VxbuskMqB0dejKRkEfhUtABWTreozQmLT 9O2nUrvIiyMiFB96Vh6LkcdyQO/FzU9Qh0rT5by43FIx91RlnYnCqo7kkgAepqnomnTW4lvtQ2nU rzDTYOREo+7Ep/urn8SSe9AFvTdOh0qwjtLfcUTJLMcs7E5ZmPckkkn1NW6KKACiiigAooooAKKK KACiiigAoopCcCgBHcIMmsGTxJLdTyRaLYyX3lsVecuI4VYdRvPLEf7IOOhxUPiW5luHtdKtpXik v5vKaRDhkjALOQex2qQD2LCta2tobK1itraJYoYlCIiDAUDoBWNWryaLcDN+3+Jf+gVpn/gxf/4z R9u8S/8AQL0z/wAGL/8AxmteoWvIFvksy/8ApDxtKqYPKqQCc9OrD86w9vMRnfbvEv8A0C9M/wDB i/8A8Zo+3eJf+gXpn/gxf/4zWvUN5eQWFq9xcvsiTG5sE4ycDge5o9vMZlT3nipoJFg07So5SpCO 1/IwU9iR5Iz9M1X0uPxDpVgltFpmnORlnkfUX3SuTlnb9z1JJNb81zDbmITSKhlcRpn+JiCcD8jU lHt5iMC+uvF81sUsrLSbeU/8tWvXk2jvgeUOfTOR7Gq2ny3Hh1pLnUtIlkeQfv8AUIp/tTkf7Xyq wX2VcD0FdFFeQTXU9vG+ZYNvmLg/LuGRz34qaj281uMktbuG7gSaCRZI5FDI6nIYHoQanrkrJF8P +JH0+BRHY3kbXMEYGFjcMBIoHYHcrY9S1dWjblBrrjJSV0A6iiiqAKKKKACiiigAooooAQ9K5fxV pz39jJEjbGOCrYzgggjjvyK6moJ7cSjBFAHnFx4g8UwuQLizb/t1P/xdQ/8ACT+K/wDntZf+Ap/+ KrvZNFjc5Kimf2FF/dFR7OHYDhf+En8V/wDPay/8BT/8VR/wk/iv/ntZf+Ap/wDiq7r+wov7oo/s KL+6KPZw7AcL/wAJP4r/AOe1l/4Cn/4qj/hJ/Ff/AD2sv/AU/wDxVd1/YUX90Uf2FF/dFHs4dgOF /wCEn8V/89rL/wABT/8AFUf8JP4r/wCe1l/4Cn/4qu6/sKL+6KP7Ci/uij2cOwHC/wDCT+K/+e1l /wCAp/8Aiqke58Qa9atZ3t1bLbylfM8u2wxAIOAS3HT0rtv7Ci/uipodJjiOQoo9nFdAHaVEY4VB 9K0qjjjEYwKkqwILpd0JFef6pbanp2rXN5ptxGnnoiOkkO/7pbBByP7xr0Vl3DFUrjTkmPIpNJqz A81Ot+Jwcedaf+Ax/wDiqT+3PE//AD2tP/AY/wDxVegHQos/dFH9hRf3RUeyh2FZHn/9ueJ/+e1p /wCAx/8AiqP7c8T/APPa0/8AAY//ABVegf2FF/dFH9hRf3RR7KHYLI8//tzxP/z2tP8AwGP/AMVR /bnif/ntaf8AgMf/AIqvQP7Ci/uij+wov7oo9lDsFkef/wBueJ/+e1p/4DH/AOKo/tzxP/z2tP8A wGP/AMVXoH9hRf3RR/YUX90Ueyh2CyOBTWvEzNgz2g/7dj/8VW34esryTU5r+/mSSaVEj+SPYAFL EcZPPzGukXQ4gfuirlvYrD0FUoRTukFi1EMRgU+kAwKWqGFFFNdtq5NAAWC9ayL/AMVaXp85t5Ln zLgcmCBGlkH1VASPyrK1S+udZ1STTLOZ4LWAD7XPGcOSRkRIexIOS3UAjHJyLFnY22nQCGzgSGMc 4UYyfU+p9zWFSsoOyJcrDj4wU/c0nVWHr9n2/wAyDSf8Jef+gPqv/flf/iqnqOa5ht9vnzRx7shd 7AZwCTjPsCfoDWX1iXYXMxn/AAl5/wCgPqv/AH5X/wCKo/4S8/8AQH1X/vyv/wAVUyOsiK6MGVhk MDkEetNmmjt4XlmkSONBuZ3YAKPUk9KPrEuwczMjSNfn0qW5tU0fU208t5lt+6XdFuJLR43fdB5H scdhnT/4S8/9AfVf+/K//FVPRR9Zl2DmMa81+a+1qzlm0fU/sVoDKq+UuXmPCkjd0Ubj9WB7Vpf8 Jef+gPqv/flf/iqnqE3duLZ7gzxCBN26TeNq7SQ2T0GCCD9KPrEuwczE/wCEvP8A0B9V/wC/K/8A xVH/AAl5/wCgPqv/AH5X/wCKqZmVMbmAycDJ6mlo+sy7BzEH/CXn/oD6r/35X/4qnDxjCnM+napC vdjaM+P++M05Zo2meJZEMiAMyBhlQc4JHbOD+Rp9H1mXYOYu6brun6srGyuopinDqp+ZD6MvUH61 oA56VymoaRb37LKd0N3GP3V1Cdskf0PcexyD3FW/D2sT3DTWOo7BfWpAkKDCyqc7ZFHYHB47EEc4 yd6dVT06lJ3OhopAcilrUYUUUUAFMk4Q0+msMqRQBxt9MIvGWjvJ9xnlhBPZmQkf+g4/GuprlvFe mNdQHYzI6sHjdeqOpyrD3BANM0jx1aeUtvr7pYXqDDSOCIZf9pW6Ln+6xBHTnrXLXg2+ZAWPG0Fz cWNisQ3WougbtTbvODHsbG6NCGZd+3IB9zwDWBHpt2LJQ4vzAbK6VXjs2Vo1aeIqojLFtuASEJ3F RjA6V1n/AAl3h7/oPaV/4GR/40f8Jd4e/wCg9pX/AIGR/wCNYpyStYRxklndGztEazji0uO6lMgX T55IZCY02P8AZ9wdVzvGOV3c981s3FvcyeAhpckd9NctArZMDo23zRgdWwwXHG4nAya2v+Eu8Pf9 B7Sv/AyP/Gj/AIS7w9/0HtK/8DI/8abb7Ac3d6BFa6vsi0x/sEOo28yKsLOq5jYOyjB/i25I78mo LLwpFN/Zhu9PnbzLW7N1vD/M+9PLD/QFtoPTHHSur/4S7w9/0HtK/wDAyP8Axo/4S7w9/wBB7Sv/ AAMj/wAaOaQFDwdBeRiWS+inSWS0s9zSqQWcRDd17g9feumrI/4S7w9/0HtK/wDAyP8AxqnqPj7Q bG3d4b2O/kAJEVmwlJx6kfKv1JFS1KT2Aj16UN4u0iJD88UE8j+wYoB+eD/3zXV2pzCM15TovivS p9Sn1LVdXtBdXBGQH+WNBnag9hk89ySe9er2pVrdGRgysAQQcgiu6nHlikMmoooqwCiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKqX8hSEkelW6q3sfmQkUAcj4ZkDrqSn/AFq30hk9ecFf/HStbVcjqQvNC1htRsk8xXAW4gJw JVHQg9mHOD36HsRsaZ4m0vVcJBcrHP3t5vkkH/AT1+oyPeuGtTak30IkjWrzue9827tZW1KZ9RE1 4ZrYy5EBWKYLhf4cDGP72c816JSYAJIAyetZxlYk4q21GUa5Z+ZfPKWMCCGO5Kum6Nc7oSMOpJLb xyOfQ1kpqJufCqmLUp76a40eV75JJi4iYKu0kfwnJI7ZGTzjNel7Ru3YGcYzUFhZQ6dYQWluCIoI 1jTJycKMDJ+gquddh3OQutZlTxSnkXJU/bvs7RS3Z5GwgDyQMBS2CHJySR6iq39pzJ4f+02erXE1 +8EZv0eUlbdmkQSEnB8oqC4wBwATj5a7/AznApcDnjrS512C5wcN/IUiju9WWLSmvShuIb55NuIs iMzsq5BbnIJ5+XPanxXMTfDW+txc75nivJFL/fdRM4LkfUj867jYu3btG30xxS0c/kFzhtVt/s99 LaT3129rBc2M++W5bKF3dWO7PA+UHHQHpinWdvc3t3YebqmoBbue8SVUuCo2o7bAuPu4wORyenTi u3oo5wucr4OuZbyd7i4cyTSabZM7nqx/e5JrqqKRmCKWYgKOSSeBUyd3cQtYyygeOFEfVLECXHu/ yfyf86r6l4xsbctBpxGoXnQJC2UQ/wC2/QfTk+1P8LadOJZLq7cy3Vw++WTGMnsAOygcAeldFCm7 8zKijuIjmMGpKZENqAU+ussKKKKACiiigCpeWizoQRXLaj4ZWZiQtdpTTGrdRQB5s3g8Z+4Pypv/ AAh4/uD8q9I8hPSj7PH6UAeb/wDCHj+4PyrlBNbW/ju48P3gjQHYIHIx85UHafrnj34717n9nj9K 4PV/hHp+teLH1m8u53WaUNJAPkAUJgAMOc7gD24yPegCn/wh4/uD8qP+EPH9wflXo620aqFA4Axy c0v2eP0oA83Hg8f3B+VaFj4VWNgSv6V3HkJ6U4RKOgoA8s1r4L2mp61aXljKtrA0oN5Djgr1JT0Y 9MdOc9sHuhDr+mACGa21WBf4Jx5EwH+8o2Mfbav1rb6UtAGKnimyjdYtTSfS5icBb1Nik+gkBKH6 Bs1sqwZQykEEZBHeqWr6np+l2ivqkqRwTSLAN6lgzN0GAD7+2OtUm8L2sDF9InuNKcnOLVgIifeJ gU/EAH3oA26KzobibT1t4tWvIJpriXyYWigaPc21mwRubnCk54HFXLa5hvLWK5tpFkgmQSRuvRlI yCPwoAlooooAKKiFzCbs2wkXzwgkKd9pOM/mDUtABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFIy7hg0tFAGNqWlLcqflFcfqfg+K4yJIUdfRl BFekEA9ajaBG6igDyX/hCEThIyg9FYgfpSf8IX7Sf99t/jXq5soz2FVdQey0uze5u2CRrgcDLMTw FUDkkngAcmiwHj/iHQzoWjy34tZrhYyNwWUjaD3PPT6etYfhDT7/AMU3c1yVMVlB8pVC2HY9BknP A5/KvarPQpdVnW/1mIRopzbWBIKxejSdmk/Re2TzWhpvhzTtHtPs2n2yQQ72fYvTJOT/AJ7dOlKw HmZ8GhQSQ4A5JMjf41XtPDUN4zrD5h2d97c/rXrV3pNvdWskMuQjDBKnB/Osnw74citIlu1kdhcR A+Ww6A8jn6VLvzKxLvdHCf8ACF+0n/fbf40f8IX7Sf8Afbf416t9hi9BR9hi9BVWKPKf+EL9pP8A vtv8aP8AhC/aT/vtv8a9W+wxego+wxegosB5T/whftJ/323+NPTwNE7AyQCTH9/5v516p9hi9BSi zjHYU7AcZpXhZINuEAA6ACutsrJbdAAKtrEq9BTqACloooAKKKKACiiigAooooAKKKKACqWr2L6j pktvDL5MpKvHJ/dZWDD9QKu02RFljaNxlWBUj2NADqKqaVaSafpFnZzTedJbwJE0uMbyqgbse+M1 boAKKKKACiiigDkvE+k3/iPVxZQLDHZ29o++S5hZkd5gU+XBHzKobnt5lMlnuJ/Cyy3em3cmsCwe CUCOVQcOqScj1I3AD5ivSuwooA850rTp5L5LVrN2sRqaShUsJLeHy2tZEYhGzhd3Byepz/EM5SaR drpGmwSW08EcekRRW6f2ZNK8V0CwlK7WQRybtpDtweoOM59booA4Gfw9LcNqE1zb3UtxNq1rG0mG BaAeQXKgdFJDZI9DzxUd3prWgn05dNI04anI8IktJbiGNfJjIxEhG4F2fHO0EHvivQqKAPLV0zUW 0pZY7K6XUm0dIDK1u/mZSYiRc8Hd5fQZBbsT1rqfBVo1sL9o9y2junlRrYvaRqQvzFEd2bnjJwBk HrzXR3UMlxbtHFcS2znpLGFLL9NwI/Ssj7ZrOk/8f9supWw/5eLNdsqj/aiJ5+qEn/ZoA3aKqafq llqsJlsbhJlU7WA4ZD6Mp5U+xANW6ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiis7XtSOk6HdXka75UTEKf35GO1F/FiB+NAFu3u7e7V2tp4pljcxuY3DB WHBU46EdxU1cDoEE3hya+0vVtunW91YfaBPFc7jvjQJNJu2jDEFG6dQTTdR114fFUZgvWRYr+C3d Jb0gmNlUEiADBU7s+Yxzk8dqAO7huYLlQ0E0cqkZBRwwIzjPHuDUteURzTadZyXdlNIl4dK/dgzM AF+0sJGC8j5VO7ODjritG1uL29a3tIdXb7HNqUcQks797lgPIlZ085kXOSqnjO0ntxQB6NWPBpbt qB1TWJY3miyLeNT+6tl6EjOMue7Ed8DAznnbWa6tru01Br++lL6zd2rQtKWQwr5+1QncgoCD17Zx xXPz6o+o6TqMD3zyQXGlG5I/tBpn3q6klsACNtrfMi5AFAHrVFedDVL5/E7RxajErJfQw28T38hM lsQmSIQhEgZSx8wtwe4CmvRaAKerOY9KuShw5jKr9TwP1NWo0EcaoowqgAfSqmqfNHbxf89LiMfk d3/stXaXUXUKKKKYwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigClpWnnTbWSAy +YGuJplOMbRJIz7fw3Yq7VKy082d7qE4l3LeTLNs242ERoh5752A1doAKKKKACiiigAooooAKKKK ACiiigAooooAzdR0Gz1GYXJD294owl3btslUemf4h/stke1VPturaNxqMB1G0H/L1aR/vVH+3EOv 1TP+6K3azdb1YaRpk10I/NZANqbtu4kgAZ7cmgCzY6haanbC4sbiOeInG5Gzg9wfQ+x5qzXE31lq 93dG8t9Ihsr4jH2m21DazegYeXtcezA1bsb/AMWRw7L7TLCaQf8ALWO7KBh7rtOD+P5VHtYdwOro rnP7S8Q/9Aa1/wDA/wD+wo/tLxD/ANAa1/8AA/8A+wo9rDuB0dFc5/aXiH/oDWv/AIH/AP2FH9pe If8AoDWv/gf/APYUe1h3A6Oiuc/tLxD/ANAa1/8AA/8A+wo/tLxD/wBAa1/8D/8A7Cj2sO4HR0Vz n9peIf8AoDWv/gf/APYVHdeINY063Nze6RAtujKJGS93MASBkDYM9fWj2kX1A6eio45BIMipKsAo prNtGa52/wDEd7Hq81jp+npcmGJJJHe48vG8sAANpz900m0ldgdJRXLf27r3/QGtv/A7/wCwo/t3 Xv8AoDW3/gd/9hUe1h3FdHU0Vy39u69/0Brb/wADv/sKP7d17/oDW3/gd/8AYUe1h3C6Oporlv7d 17/oDW3/AIHf/YUf27r3/QGtv/A7/wCwo9rDuF0dTRXLf27r3/QGtv8AwO/+wo/t3Xv+gNbf+B3/ ANhR7WHcLo6miuW/t3Xf+gNbf+B3/wBhVvRtfnv726s72zW1nt0jfCzeYGV92OcDn5D+lUpxbsmF zeopAciiqGLSbRnOBmsq58TaXbTGBLkXNz/z72imaT8VTJH1OBVcxavrfFwX0ixPWONwbmQehYZW Mf7pJ/2hQBLfa1I922n6NEl1fLxK7H9zbZ7yEd/RByfYc1q28bRQIkjKzgfMyrtBPfA7Co7KxttN tUtrKBIYU6Igx9T7k9z3qxQAUm0DoBS0UAJtXcDgZAxnFLRRQBSu/m1KwT0Z5PyQr/7NV2qT/Nrk X/TO3f8A8eZf/iau0kJBRRRTGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAUo9 P8vXLjUBL/r7eOBo9v8AcZyGzn/poR07VdqlNp4l1q01AS7Wghlh2Y++HKHr7GMVdoAKKKKACiii gAooooAKKKKACiiigAooooAQ9K4/xtMRpTr6yRj/AMfWuwPQ1xXjj/kHn/rrH/6GtJ7AdXRRWfra apJpxXRZII7ncMmX+73CnBAb0JBHtXmoRoUV59qdlO6Wwe21EKJwdQN/C94sg2P5Z2xsAyBs8LgA lSVFEHh6S9tSl/b3VykemTeR5sLx7WMrmMBdzEMFxtBO4DHQ5q+RdwO9juYZZpYY5FaSEgSKOqkj Iz+FSV55/Yj3N463FhcCS6uLKSd1idd6eXh9zAf3s5Ge/PWrf2EJ4gudImglbS7PzNRCxBiSJEKL GAvOdxnIA9Fo5F3A7iiuX0z+17GeS4dbwaOkZIt7s/aLontsCZOPZmZvYVvtfoszRmG5JWVYsiFi pJUHIOMbecFugPFS1YCzWJ4zOPCl6fQJ/wChrW3WF41/5FG//wB1f/Q1oh8SA1tKlMkKk+laVZGi f6hfpWvXpDILptsJNcbpshk8V6wT2gtx+stdhe/6g1xej/8AI1az/wBcbf8AnLWVf4GKWxv0UVzW qQam9/K1+LmfSs/JHp77GA7+YOHb/gDc/wB2uFK5mdLUdxcRWsDzTuscSDLM3QCuFsrG8/tku4lW 6FzMzMtjJuaDDbFMpfaU2lcKBkEDjIJqOfw80WhxRxafMzTaLm5UxsxeZTEV3A/x8vgde3aq5Ffc dj0KiuLl0pYbfWNWit5Y5ra5S4ti6sv7mOOJiqqcYBAZT7/Snw2k7WcNxbwakNWuw1yZIZNiRh2L Kr7sodowMYYjHSjl8wsdjRWZZ3l1a2Sx6qplvI4w8rWsDmNssQAvHJGOR+OADV+KcTNKAki+W+w7 0KgnAORnqOeo9/SoaESVzT2a3njW8V7i7iUWsGVgnaLd80nUqQf1rpawYf8Akeb3/r1t/wD0KSts P8ZUdzfi8Kaa0YLtqDn/AG9SuW/m9P8A+EQ0M/63Topx6XBaUfk5NasH+qFS13FkNtaW9nEIrWCK CMdEjQKB+AqaiigAooooAKKKKACiiigClD82tXTdlhiX8cuT/MVdqlY/Ne6g/wD02VB9Ai/1Jq7S QkFFFFMYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBS1GwW9lsZTL5bWlyJ1OM 5+VkI/EOau1S1fT11TS57RpPK3gESYzsIIYH8CAauAhgCCCDyCKAFooooAKKKKACiiigAooooAKK KKACiiigBD0rifHZEelSSOwVEdGZicAAOMk121ZOq2AuomUgEEYINAEP/CSaL/0GNO/8Ck/xo/4S TRP+gxp3/gUn+NcpdeD4pHJEKf8AfIqv/wAIXH/zxT/vmub6su4HZ/8ACSaJ/wBBjTv/AAKT/Gj/ AISTRP8AoMad/wCBSf415F42j/4RW3iMemeZ53AnZf3aH0Pv7cfjzVvwZ4Wm1Hw9HqF6u+S6YyKG XG1egwOw4z+NH1ZdwPUv+Ek0T/oMad/4FJ/jUFvrHhy2lmlg1PTFknbdI4uUy59zmuT/AOELj/54 p/3zWfpPhKOQXkRiUtb3UiH5emcOP0cUfV13A9D/AOEk0T/oMad/4FJ/jR/wkmif9BjTv/ApP8a4 z/hC4/8Anin/AHzR/wAIXH/zxT/vmj6su4HZ/wDCSaJ/0GNO/wDApP8AGsbxdrulXPhi8ht9TspZ X2KqJcIzMd68AA81i/8ACFx/88U/75rR03wrFbyq3koCDkHaOKaw6TvcDqdFGIF+la1VLGDyYwKt 10AVr0ZgNcHZahZ6f4r1cXl3b25eG3K+bIqbuZOmTXoMyb4yK5PWfD6XrlnjVj6lc1M480bCauO/ 4SDR/wDoK2H/AIEp/jR/wkOj/wDQVsP/AAJT/GuebwZGW/1Kf98ik/4QuP8A54p/3zWH1Zdxcp0X /CQ6P/0FbD/wJT/Gk/4SHR/+gtYf+BKf41xl/wCGA92mm2cafaZF3yOFH7mPpuPuegHrk9jV+LwP DDEsaQIFUYHy0fVl3DlN+61XQL6AwXWo6dLE3VGuEwfrzyPapv8AhINH/wCgrYf+BKf415SZLVPi MdFYR+QVEA4GPN6/nk7frXaf8IXH/wA8U/75o+rLuHKdF/wkOj/9BWw/8CU/xo/4SHR/+grYf+BK f41zv/CFx/8APFP++aP+ELj/AOeKf980fVl3DlOi/wCEg0f/AKCth/4Ep/jWZp11b33jO9ltJ4p4 xbQAtE4YZzJ3FUo/BkYcHyU/75FdPouirZABEVfXAxVwoqDvcFGx0cH+qFSU1BtUCnVsUFFFFABR RRQAUUUUAFFFISACT0FAFPSvmt5pP+elxKfwDkD9AKu1S0cEaRak9XjDn6tz/WrtJbCWwUUUUxhR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFACMoZSrAEEYIPeqej2aadpNtYxTectr GsAc9cKMDPvgVdqjZWkFjfXojmy93J9pMRIyvyqhIHXB2g/UmgC9RRRQAUUUUAFFFFABRRRQAUUU UAFFFFABTSobqKdTWZUQs7BVUZJJwAKAGGBD1FZF7qsS3T2Ol2/2+/Xh0VtscPvI/IX6csewqIXF 54mz9ilkstIP/LyvE10P+mf9xP8Ab6n+HHDHZsbG2021S2soEhhToqD8yfUnuTyaAMaPwlbXgkm1 /wAvUbmZDGQyYiiU9VjX+H3bO44HPAA17XTraztYra3iWOGFBGiDoqgYAq1RQBF9nj/u1i6bAkPi nWrfHEi290P+BK0f/tEVv1iy/uPG9se11p8qn6xyIQPykb8jQBq/Z4/7tH2eP+7UtFAEX2eP+7Si FB0FSUUAIAB0paKKAEprRK3UU+igCL7PH/drP1i8i0u1Uxw+fdzt5VtADgyyHoM9gOST2AJq7e3s GnWUt3dyCOCJdzsf88n271m6PZT3F02sanGUu5V2QQN/y6xddv8AvnALH1wOiigCXR9EXTrZ2ncT 3tw3mXM+Mb39h2UDgDsB9TWh9nj/ALtS0UAefXnw78PReOLK5ktJD9sM8pbz3B+0BldTkH08w49q 7z7PH/drJ8VfuNLj1Efe024S6J9EB2yf+Q2etqgCP7PH/do+zx/3alooAi+zx+lOWNV6Cn0UAFFF FABRRRQAUUUUAFFFFABVTVJDFpV0y/e8pgv1IwP1q3VHVPnigh/57Tov4A7j+imk9hPYtxRiKFI1 6IoUfhT6KKYwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACikZgqlmIAAySe1Ul1vS3t TcrqVm1uGKGUTqU3AEkZzjIAJx7UAXqKpy6vp0NrFdS39qlvMQI5WmUI5PTBzg/hT5dRs4LuK1mu 7eO5mGY4WkUO49lzk0AWaoXlvax31vqdxMYXt1aEMWAVhIVG1s/7Srj3qGy8Q219dmKKC6EPz7Lp o8QybDhsNn9SADjjNP1C40q/t/7OvLu2K38RVI/OUNKrDqnOT7EUAaVFY1n4m0251CLThOVu3M6p HKQGfyX2MeD3OSPUA+hq7Fq+nT27zw39pJCj7GkWZSqt6E5wD7UAXKKpR6xpss8UEeoWjzSjMcaz KWcYzwM88EH6GmXGvaZbRXjyX9sTZIXuEWVS0YHqM5FAGhRVGLWtOmFrtvrbddqHgUyqGlB/ujPP 4VeoAKKKKACiiigAooooAKwNQT/hINXfSyT/AGdaBWvQD/r3PKwn/Zx8zDuCo6E1v1i+FRv025nP +snv7pnP0mdB+Soo/CgDZAAAAGAO1LRRQAUUUUAFYut/udY0K57C7eBj/svE+P8Ax5UrarF8W/u9 CNz3tLiC5z6BJVZv/HQw/GgDaooooAKKKKACiiigApKWsrWrO61MRWEZMVlKSbuUNhig/wCWa98t 0J7DPcjABTtR/wAJNqKXz86VaPm0XtcSj/lqfVV6L6nLf3TXQ0yONIYkjiRURAFVVGAoHQAU+gAo oooAhuraO8tJraYZjmRo3HqCMGqHhe4kuvDVg85zMsQilPq6fI36qa1axfDHyWt/CPuxahcgf8Ck L/8As1AG1RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABVGb97rFsnaGNpT9T8q/pvq9VGx/fXd5c9i4 hT/dTg/+PFqTEy9RRRTGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBT1e3N3o17biHz zNA8fleZ5fmZUjbu/hz0z2rhZrS+tbjSnu9OnuUOqRtFHcLAtzJttp87th2HbgYJIJx9DXo1NZFc qWVSUOVJHQ4xkfgT+dAHnsnh3VkuIbw2l2sLi7C2lqbZmg82UMARKCmGH3ipOD6ir+naDdabL9lm 0k3yTLZ7biWZGEAiVFIZuGJUqWBVeS3bmu1ooA4Xw14evNJvLWP7BcRtbRzJd3DzqyXqn/VhRuJ9 D8wG3BHem67pWsXsrm10yeGPZavFFB9nAxGwYo7E7sqchQhC9OeTjvKKAODvPDWqzLOkVuY3uItV hWUOv7szyq8THnOCFI4yRkcVFF4Xu7xCZrG82GSyjeK8a2AaOObcw2RKAVUZ5JyckY9fQOtU7W9m lv7q1uLR4TEQ0coy0cyHoQ2OGByCvUcHkGgDnpfDk/mXssVlGJZNatrqNwVB8lPJBIOeAArjHXrx zWUNB1u5uczWUyFra8gcZgWFGlGV2bTvKkgZLEnJHA5x6HRQB53P4b1S4upfMtdQWO8itlVYntQs PlqAQ7MGZcMCw2Zzn1r0SiigAooooAKKKKACiiigArD0Y/YdY1PS34zKb2D/AGkkOX/KTfn2ZfWt ysnXbGeVIb/T1B1CxJeJScCVD9+In/aAGPRgp7UAa1FVtPv4NUsYru1YtFIMjIwVPQqR2IOQR2Iq zQAUUVwGra5JF4tAivGiEeoQ20kcl6VOxlUNiADG07s+Yxznp2oA71HWRdyMGHqDmqur2I1TRr2x JAFzA8OT23KR/WvP9LmtLW1trS/1i4sbFVvG3i9ZGNwsxG0tnOQuCE77iSDT3m1i7sJrq61O+tr2 IaahSKTaqPLsWUlOhJ3Hg8A9KAPQ7cypZxG6KCVYx5pB+Xdjnn0zQby2FoLo3EX2ZlDibeNhU9Du 6YORXM6fKII7+1uNSuh9k1J4rUyzlnl/0cP5bMeWHzOcH+6PSuVvdRN1oH/Ex1a4iuxaWJtbYTYF wrIhdyn8eWLgnnbtzxQB6tUN3cJaWc1xIwRIo2dmPQADJNTUjKHUqwBUjBBHBFAHm93q+r3Vhe2k 95eRHybS5SWSOFJPmm2naqZwh4wG+bg5raj1XVPtaXRvd0f9qnTzZGNMFASu/ON2/A8zrjHGO9bs fhzRoY3ji0qxRHQxsq26AMpxkHjkcDj2FSpo2mxX/wBvSwtUuwMeeIlD4xj72M9OPpQBxFrqniO5 sLOZtaCm50iTUDttY/lZNmFHHQ7+c88cYzW5f3072+k3jvHKLm4tWFv5SkxEqxJBPOTxj0x71f0Q 2up2RuI9PtorPDQWmEHz2/AzjHCMRkL0ICn6aA02yDhxZ24cbMMIlyNmdnbtk49MmgDj9Dur2+8Q eH72+v0uDe6bPcCFY1XyCTCdoI5IGcfNzlT9B3NUbXRdMsbl7m00+0gncktJHCqsc8nkDPJq9QAU UUUAFYvhb95YXdwOk9/cuvuBKyg/iFB/GrWu6i2l6PPcRLvuMCOBP78rHai/ixFSaTp66VpFpYox YW8Sxlj1Ygck/U8/jQBcooooAKKKKACiiigArnp/FS2er6haXFlP5dqIBEybSZ3kJAVRnqT64HBz gCuhrn9S8NTXmo3F5b3kcMknkSR74S/lyRMSCfmGVIYgjg89aABvGNqPLjFjqDXjyvCbRY1MqOqh yD8237rAg5wQetR2vjBNWtm/sixuZLiS3+0WguFEaTruCkg5yACwzkA+mamsvDckOqR6jc3aSXXn STTbItquWjWMAZYkAKi+ueelVD4PuI9NtLez1XyJrbTmsFm8gnILRktgMCOIyODn5s54oAt6Xrtz NPeW13Ck8lrPHA0tkCyFnAzkE5G3Pzcngj6VFqPi1La11ARWlxFPDa3E9s1xGBHOYhzjDbsZx1Ay ORVvS9L1DTrFLUXOnJHG6bFtbFolCA5ZcGVuT69uuDWF/wAK+kLSE31sHkguLd5hZ/vZRKpG6R9+ WYHGOgxngZGADQg8Yfvb+O50+5DwXaWlukQVmuWaJZMKN3HBJ5wNuDnOQJY/Fth5trbwWt2ZZ/NJ iSEZh8twsm/nAwW69+2cjNK/8HJf3Nz/AKTaSt9qivEhuLXzUVhCISHXd8ysqgjoQecmrmmeFV06 SGQTQKUtp4WSC1WFMyurZVVPAGzGDknuaAFsfGNnfxGRbS/jU2n2yHzIeZ4+OUAJJOSBg46jsc1H P4v2yW0UOm3fnNepaTwybA8O5N4PDEHIx0J796bceD2l0+0to9QMbW2m/YA4jPz8xHccN0PlYK56 MeRUNn4LkspWkhurOHN3DdrHBZeXGhRShUKH6EHrnOcnnpQBp2Hie01G9jgihuUSbf8AZ55EAjuN n3thzn35AyBkZrZrltA8FRaFqEUsf2AxW4cQtHYqk7Bv78uSTgHHAXPeupoAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACobqF57SWKKZoJHUhJVAJQ9jg8HHoamooAq2c0y 28EeoNCt4wIYRn5XI6lQecd8ds1aqrqGm22pwLFdJnY4kjdTtaNx0ZSOQaZNfTQanDbtZytbTLgX MZDBH5+V16gYxhuRk4OOMgF2iiigAooooAKKKKACiiigAoorgNYudRgXXLyK/uAialFaYa4McVvA VhLtkA7eSQXwdoJIxyaAOpTTJ7HW2urBkFrdHN3AxIw+OJE4+8cAMO/B6jnWrzaDU2M9jDqWu+Rp j3NwiywahIylVjjIU3DKhbDlsMP93JOafBfaxcWtzdw3d681no3n20JPE7751jkdcfMSqqcdyR6C gD0ak2jOcDNebW+pXR0298rXLX7NttiZDqU06q5f5g0/ljyt68cZ28HAzXYeEro3egxuXmfbJIm6 WYTZw5HEn8a9gx5IHPNAGyVU9QDznkd6WiigDPGoSL4ifT5FQRPaieFhncSGKyA+wzH+Zq/gZBwM jvWLr/8Aot/pGpDgQ3P2eU/9M5hs/wDRnlH8K26ACiiigArE8SSPdR2+jQMVl1FikjKcGOAf61vb ghQexcVt1h6N/wATHV9R1ZuY932K2/3Iyd7fjJuHuEWgDajjSKNY41CIgCqoGAAOgp1FFABVLV9V g0XTZL66EhijZFIjXc2WYKMDvywq7VHV9O/tWw+zeb5X76KXdt3fckV8YyOu3H40AUD4ttVuBHJa XqKrRpPI0Y2WzyY2o/PX5lzjIG4ZIpkPjKymJb7LexwEzKk7xgJI8W4uq85zhGPIAODzxVa78FRX Gvz6gv2ApcTRzymexWWZSoUYSRjhQQo6qcckcnjP0XQbjVtNWO41GI21rc3hjijhyySO0qfM+7Db RIxwADkjPSgDUfxdYXFvbzf2bfT5Q3aL9nUvHEOBLgngHJxj5jzgVdh8TWlzqQtbWG5nTKK1xEga NC6B1Dc7hlSDnGOetZmqeCEvpbSVHsXlhs1s2N5Yi4G1eQ6AsNrcnrkHPPSpm8JMdZtrtbi2WO2M ZjZLUJOqooHl71IGw4zgqcZIHbAB0tFFFABRRRQAUUUUAFFFFABRRRQAVDdXCWls80mSFHAHVj2A 9yeKlZgilmICgZJJ4ArPt86lOt24P2ZDmBT/ABn++f6fn3GE2Jk9hbvDCzz4NxM3mSkdAfQewAA/ CrVFFMYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFAFKLS4oNTkvYZZ0aYYli8wmNzxhtp6Nx1GM980Wd5czXM8F1YyW5jOUk3B45VzwQRyD6ggfj 1q7RQA2ORJY1kjdXRhlWU5BHsadVK10m009LgadCloZ+W8pcKG/vbemeeeOe9NtW1C1sZm1ExXUs eShtYyhkUDptYnDde+PpQBfoqrY6hDqFt50QmjAbayzRNEyn0IYA9/xq1QAUUUUAFIRkYNLRQBVl 0+3mvLa5dT5lsrrGB0AYAHj8BVqiigDK1W9uNKZbg2yz6bgi4Eakyxf7eP4l9QBkdeeg0YJoriCO a3dJInUMjocqwPQgjtUlc/NaT+HJ3u9MiebTnYvc2SDLRk8mSIfqU79RzkMAdBRUNpdwX9pHc2kq TQSruR0OQwqagCjrWn/2rot5ZBtrzRMqP/cfHyt+BwfwpdG1D+1dGtL3btaeJWZP7jY+ZfwOR+FX axNC/wBD1PVtLPCxzfa4R/0zmyx/8iCX9KANuiiigDO16/fTNEurmEBpwuyBT/FKxCoPxYqKm0uw TStKtbGIllt4lj3Hq2ByT7k8/jWfrH+ma9o+n9VV3vZR6rGAFB/4G6H/AIDW3QAUUUUAFISAMngV DeXtvp9pJc3kyQwRjLO5wB/n0rF+zXXic7r+OS00jqto3yyXPvL/AHU/2Op/i/u0AEl3P4mdoNMl eDSwSs18hw0/qkJ9PWT8F55G3aWkFjax21rEkUES7URBgKKkRFjRURQqqMBQMAD0p1ABRRRQAUUU UAFFFFABRRRQAUUU15EiQvIyoqjJZjgCgB1Rz3EVtEZZnCIO5qp/aElzxp8JkB/5bSfLGPp3b8OP enwWAWUT3MhuJx0ZhhU/3V6D+fvSv2FfsRiKTUyrXMbRWoOVhbrJ6Fx2H+z+fpWhRRQkMKKKKYBR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQBFcW0N5byQXMUc0Mg2vHIoZWHoQetVl0wWumNZ6ZK1pjmNv8AWbOc4AbPHbHvxir1FAFE yX9npYeWJdQu0+8tuBFvGewdiAcdi1K2rW1vp8d5ft9gjcgH7UypsJ4AJzj9au0jKGUqwBB4IPeg BI5EljWSNldGGVZTkEeoNOqndaXBdWaWytNbIhDIbWQxFSP93HHPQ5HtTbmLUIbGFNOlhlmjwGN3 n96AMclehJwc4I68UAXqKo3mpf2dawy3VtcNuwJPssbT+Wcc8KNxHuF/AVbWVG2YYZcblB4JH0/G gB9FFFAGFd6fc6Pdyajo0Zkjkbfd2AOBKe7x9lk9R0bvg81qWGoW2p2aXVpIJInzzjBBHBBB5BB4 IPINWaxNQ0y4srx9U0VQbhsG5tSdqXQHf0WQDo3foeMEAG3WJqv+g+INK1AcJKWsZj7P8yE/R1Cj /rpWhpupW+q2a3NszbSSrK67XjYcFWB5BB6ioPENmb/QLyBXWOTy98TscBJF+ZG/BgD+FAGlRWP4 f8T6Z4jt1awuopZhDHLNEjZMW4dD75BGO2KsarrumaGkTapew2qykiMytt3EDJAoAqaZ/pfibV7z qsHlWUf/AAFfMcj8ZAD/ALlbdY/hSNl8O208gxLd7ruTnOGlYuR+G7H4VsUAFZ+qazBpnlx7HuLu bIgtYeZJT39gB3Y4A9aq3usTT3b6doiJPeJxNM+TDa/72PvN6IOfUgc1Z0vRodM8yXe9xeTY8+6m 5kk9B6BR2UYAoArWejz3N3HqOuMk10h3QW6HMNr/ALufvP8A7Z/AAddqiigAooooAKKKrz31rbHE 9zDGfR3ANAFiiqP9rQN/qUnm/wCucLEfnjH60fa7yT/Vaey+88qr/wCg7jSuhXL1FUfL1KT709tC PRIy5/Mkfyo/s0yf8fF5dS+wfyx/44BRcLlqa4htk3zyxxL6uwA/Wqv9qxSf8esU9yexjjIX/vo4 X9akh02zt33xW0Qf++Vy35nmrVGoalH/AImM/wDzwtV/GR/6AfrSppcG8ST77mQchpjuwfYdB+AF XaKLBYKKKKYwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAqnqGlWOqxKl/aw3CocoZFBKH1U9Q fcVbZgoyawr/AFueS/Om6RAtzeqoaQu22K3U9C7AHk9lHJ9hzQBoX8F5K8T2N+LYx53I8IkSQcde jDp2I685pt5qb2l1Cn2K4nhkIDTQ7WEZz/Eud2PcA1QXw1Pc/Nq2r3twx6x2zm2jH02Hf+bGn/8A CHaP3huWPq17OT+ZegDWF1AZjEJU8wKGKZGQD0OPTg0/zU9awJPAfh6WZJpLF2lj+45uZdy/Q7qm /wCEN0b/AJ95/wDwLm/+KoATVLKa2um1fRgDeBQJ7bIVbxB2J6Bx/C34Hjo2/g0vxz4XntJWf7Pc DYwI2yQyKe47MrDofT0p/wDwhujf8+8//gXN/wDFUxPBGhRyO6WkqvIQXYXUoLY45+bmgDi/hB4e u/C+seJLLUEKvG0Ajkx8si/vPmU9wePp0qf4x6Nd+I7bRLHTYjLO90w9lBXlmPYD1rsP+EN0b/n3 n/8AAub/AOKo/wCEN0b/AJ95/wDwLm/+KoAZ4R8O2fhDw/Fp1vKZCvzzSsfvuepx2HHT+uTUb6hP 4kcw6ZO1tpYOJb5OHn9Vh9B6yf8AfPqJZPBOhzRNHJazMjgqym6mIIPUH5qVfBmiqoVbaYADAAu5 uP8Ax6gDSsra0020S1s4khhT7qr+pPqT1JPJqx5qetY3/CG6N/z7z/8AgXN/8VR/whujf8+8/wD4 Fzf/ABVAGu9zFEheSRUUdSxwKrf2vbv/AMeyy3J/6YoSv/fRwv61QbwXorYzbzgjoVvJgR+IfNI3 hy5tPm0nV7yFh0iumNzEfruO/wDJqWotTQ87UJf9Xawwj1mkyfyUY/Wj7JeSf66/ZfaCJVH/AI9u NUtO1uU3x07VYBa34Xeqht0c6jq0bYGccZBAIyMjBBO0DkUWCxS/sm2b/XebP/11lZh+WcfpViCz t7YYggii/wBxAv8AKpqKLILIKKKKYwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAz9WvBaWskhzhFLHHsKqeELUW/hu0mbBuLxBd3D93kcBjz3AyFHsoHapNbQvbsMZBF Y/gnXIkgTw9dtsvLNNkG7pPCvCkH+8owCOvGehoA6+sW58RrbnUM25b7He29ofn++ZfK+bpxjzen fHvW1WFe+FLe+v5bhr28jjmnhuJbeNkEbyRFdrHKlv4FBGccUAU4/F15OYRb6MW+03ktpbl7kKHM fmbmPynav7v3PPTpmw3iiVfDh1f+zm8uOKZp084ZjkjbaU6c5Ibn/Z96uW/h+1tvsWySY/Y7ia4j yRy0u/cDx0/eNj6DrUb+GbZ9Ll043F19lmW4WRAy/MZnLk525ypJ2/XnNACXfiNbXWf7PNuWPmQR 79+P9b5nOMdvL/WqF34vS2vHZ4phHbrdgxoynzWiaIDqM5JfA5A55zxic+D4nM80up6hJeSvDJ9p Yx7kaLO0gBNv8RBGMH680DwTYGF0muLyYyLcB3d13EzFC7cKMEFARjp+WABmm6zq9xrOpQXOniN7 eK1KWwmVlG95A7h8DOFA4PdCB1yZob/VW8UanYyfZTHHZxzWqLnqzyD5z152jp0qWy8OG0murhtU v5rq6EIkncxg4jYkAAIAAQxB46HseatXGjxT3l3dCaeKa5tBaFo2A2KC5DLxw2XPPPQcUAYFnqGt TS3tpb6la3bQwp5t40IWK3m34dVI4bam44PIIAJ54rnXNYmsh9hkur23N95UV7bWil5YRCWLAHCY 8z5Q3AI6e+n/AMIcDozaU+tak1mURFj2WyhArBhjEQznGCDkEE5HNWzoNw0CK2uam00T745sQKV+ UqV2rGFZeehB5AxigCxoN8mo6NBcJcSXG7crPJGI33BiGDKOhBBBHtWjWXa6GtlZC2tr28jXypEL BkLF3bcZTlfv5JPpyeKvQ27RSyO1xNIHC4R8YTAxxgDr1Oc/hQBNRRRQBheMoR/wjd1ergXGnKby F+4aMbiM+jKCp9mNadlP50KsO4zXM+MtajuifDlmfMnuQBdsv3YIcjKt/tOOAPQk+meg0tSIFz6U AaFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAV7qASx kYrhvEPhpblt2zlTuVhwVI6EEcg+4r0CoZrZJRyKAPNbfX/FOjjy1uor2JegvItzAem9SD+JzVof ELXVGG0myJ9RM4/pXXz6LFIfuiqreHYifuCgDmv+Fia3/wBAiz/7/v8A/E0f8LE1v/oEWf8A3/f/ AOJro/8AhHI/7go/4RyP+4KAOc/4WJrf/QIs/wDv+/8A8TR/wsTW/wDoEWf/AH/f/wCJro/+Ecj/ ALgo/wCEcj/uCgDnP+Fia3/0CLP/AL/v/wDE0f8ACxNb/wCgRZ/9/wB//ia6P/hHI/7go/4RyP8A uCgDnP8AhYmt/wDQIs/+/wC//wATR/wsTW/+gRZ/9/3/APia6P8A4RyP+4KP+Ecj/uCgDnP+Fia3 /wBAiz/7/v8A/E0f8LE1v/oEWf8A3/f/AOJro/8AhHI/7go/4RyP+4KAOdPxB11hhNJslPqZnP8A QVWm1rxRrQ8uS8SzibgrZRlGI/32JP4jFdcvh2IH7gq5Bo8cf8IoA5vw94cSzUbY9uTuJ7knqSe5 967SCIRoBRFAsY4FS0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABSUtFACUUtFACUUtFACUUtFACUUtFACUUtFACUtFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB/9k= --Apple-Mail-45--1042582885 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit The "..." in green and in yellow are representation of the resource, just as the yellow "..." and "..." representations are representation of the resource, and the green "..." and "..." representation are of the resource. Now if I look at your definition above you are relating two resource the same way the current spec does. Say we had an "alternate" link on the green "...", then your definition would be relating the resource to the resource. But what I don't understand is that you are saying the representations of namely the green html and xhml representations are alternate versions of . How can representations be alternate versions of a resource? Perhaps you mean that they are alternate versions of the representations described by the ? [1] http://www.imc.org/atom-syntax/mail-archive/msg13940.html [2] see: http://www.imc.org/atom-syntax/mail-archive/msg13959.html > > Henry Story wrote: >> On 1 Apr 2005, at 19:52, Thomas Broyer wrote: >>> Taking back Eric's example: >>> >>> ... >>> >> href="http://example.net/somethingelse.atom" /> >>> ... >>> >>> My interpretation is that "...somethingelse.atom" is the next (entry >>> or whatever is defined by the @rel value herein) from the point of >>> view of the entry containing the link element. >> ok. <...somethingelse.atom> would be the next resource. Though I >> think the next link was meant for feeds, and has been moved over to >> the API > > document. > > This is not the same "next" relationship... yes. But it ends up being taken that way. So in the end things get a little confusing. > >> So it is a little unfortunate to be basing your argument on an example > > that is not in the spec, and that if it were would be attached to the > > feed. > > Well, feeds also carry link elements with a possible "alternate" value > for their rel attribute... > >>> If you replace the @rel with @rel="alternate", then >>> "...somethingelse.atom" is an alternate representation of "me" ("me" >>> being the entry carrying the link element). >> no. <...omething.else.atom> is a resource, not a representation [1]. >> So what you mean to say is that <...somethingelse.atom> is an >> alternate resource of me. But that won't do since "me" is a >> representation. Hence > > what we have to say is that "me" is an alternate representation of > the >> <...somethingelse.atom> resource. > > Ok, I finally understand what you mean... > > Actually, the problem is applying "alternate version" to "resource" > rather than "representation of a resource". [sniped and copied to head of mail] >> I really don't see the problem >> "..." ---alternate---> <..else.html> >> think of it as a short hand for >> "..." ---alternate-representation-of---> >> <..else.html> > > But the former one says (fmpov) something like "...else.html" is an > alternate of "entry" while the latter says "entry" is an alternate > (representation) of "...else.html". > You are switching the directions of the meanings (ok, without > switching the directions of the arrow... that's something like > active/passive forms in grammar) Perhaps we should first get to agree on the arrows we want, and then try to work out how the english is going to express the arrows we want. I think we both agree on the direction of the arrows. > >> Here we are! >> As I said above this is not a causal relationship. We are not saying >> that >> the ... representation is "known" by the hrefed >> resource, that it can produce it, or anything like that. We are just >> saying that it > > is an alternative representation (alternative is happily quite > vague) of > > the remote resource. > > yes > >>> whichever is the "primary" representation... Well, in a few words: >>> they are alternate representations of the same thing. >> "They" meaning what? >> <...else.html> and "..." are not both representations >> only the second one is. > > The problem with the web-arch "language" is that once you print a web > page (a representation of a resource), it (the printed sheets) is not > the same resource any more (if I understand correctly). Though the > still are resources/representations/call-how-you-want of the same > "thing". > >> what you mean is that <...else.html> has many representations. Some >> of these are html >> ones that it produces, others are atom ones that are produced by >> others. We have something >> like this >> <...else.html> ---representation---> "..." >> |-----------representation---> "..." >> | >> |-----------representation---> "..." >> If we now distinguish between cause and uncaused ones (call crep and >> rep) >> <...else.html> ---crep---> "..." >> |-----------crep---> "..." >> | ^ >> | | >> | similar >> | | >> |-----------rep---> "..." >> now "similar" is indeed a bi-directional representation. And I think >> you >> are speaking of the similar relation just illustrated. > > Yes, but why not call it "alternate"? no problem. In the graph I ended up calling it tom:alternate. [2] > > -- > Thomas Broyer > --Apple-Mail-45--1042582885-- From owner-atom-syntax@mail.imc.org Sun Apr 3 15:39:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21678 for ; Sun, 3 Apr 2005 15:39:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JVVBT054339; Sun, 3 Apr 2005 12:31:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33JVVwN054338; Sun, 3 Apr 2005 12:31:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from faceman.dreamhost.com (postfix@faceman.dreamhost.com [205.196.210.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33JVU7j054332 for ; Sun, 3 Apr 2005 12:31:30 -0700 (PDT) (envelope-from arve@virtuelvis.com) Received: from wintermute (ti132110a080-0138.bb.online.no [85.165.128.138]) by faceman.dreamhost.com (Postfix) with ESMTP id 2045B111D8A; Sun, 3 Apr 2005 12:31:29 -0700 (PDT) To: Atom-syntax Subject: Re: Why is alternate link a MUST? References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> Message-ID: Date: Sun, 03 Apr 2005 21:30:07 +0200 From: "Arve Bersvendsen" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <3f1451f5050403120638d8f259@mail.gmail.com> User-Agent: Opera M2(BETA3)/8.0 (Win32, build 7537) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sun, 03 Apr 2005 21:06:26 +0200, Joe Gregorio wrote: > Now the generated HTML may not be optimal but I hope this > shows that barrier to generating an HTML 'alternate' is > not onerous, and that the link should remain a MUST. This does not have to do with the _ease_ of generating an HTML "alternate", it has to do with the usefulness of generating one. Atom may well work as (and/or be extended to be) a generic data interchange format for certain types of applications where the alternate web version is clearly not useful. Think mail. -- Arve Bersvendsen From owner-atom-syntax@mail.imc.org Sun Apr 3 15:53:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22581 for ; Sun, 3 Apr 2005 15:53:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Jl4S3055229; Sun, 3 Apr 2005 12:47:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33Jl4VM055228; Sun, 3 Apr 2005 12:47:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Jl3jR055216 for ; Sun, 3 Apr 2005 12:47:04 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j33JjK77004690; Sun, 3 Apr 2005 20:45:21 +0100 (BST) In-Reply-To: <3f1451f5050403120638d8f259@mail.gmail.com> References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Atom-Syntax Syntax'" From: Graham Subject: Re: Why is alternate link a MUST? Date: Sun, 3 Apr 2005 20:45:21 +0100 To: Joe Gregorio X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3 Apr 2005, at 8:06 pm, Joe Gregorio wrote: > I agree with Sam, +1 to the required . The argument that you > can't have an HTML representation are weak, since *I* can > generate one for your feed, whether you like it or not, ala: > > http://www.rss2html.com/ > > I can also generate an XSLT sheet that transforms Atom into > HTML then use the W3C XLST service to transform > an Atom feed into HTML: > > http://www.w3.org/2001/05/xslt > > Now the generated HTML may not be optimal but I hope this > shows that barrier to generating an HTML 'alternate' is > not onerous, and that the link should remain a MUST. So do you have an argument here as to why it should be required? All I'm seeing is that it's easy to workaround when the publisher omits it. Graham Parks From owner-atom-syntax@mail.imc.org Sun Apr 3 16:09:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23439 for ; Sun, 3 Apr 2005 16:09:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33K1sat056046; Sun, 3 Apr 2005 13:01:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33K1sa6056045; Sun, 3 Apr 2005 13:01:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j33K1qPb056037 for ; Sun, 3 Apr 2005 13:01:52 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 03 Apr 2005 20:01:46 -0000 Received: from xdsl-81-173-229-88.netcologne.de (EHLO klangraum) [81.173.229.88] by mail.gmx.net (mp021) with SMTP; 03 Apr 2005 22:01:46 +0200 X-Authenticated: #163624 Date: Sun, 3 Apr 2005 22:01:53 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Why is alternate link a MUST? Message-ID: <20050403200153.GA25027@klangraum> Mail-Followup-To: Atom Syntax References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3f1451f5050403120638d8f259@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Joe Gregorio [2005-04-03 21:15]: > I can also generate an XSLT sheet that transforms Atom into > HTML then use the W3C XLST service to transform an Atom feed > into HTML: That is true, but how is the result of an operation that depends on the feed itself an alternate representation in any meaningful sense? Regards, -- Aristotle “If you can't laugh at yourself, you don't take life seriously enough.†From owner-atom-syntax@mail.imc.org Sun Apr 3 16:53:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25667 for ; Sun, 3 Apr 2005 16:53:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33KluOS059023; Sun, 3 Apr 2005 13:47:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33Klu7H059022; Sun, 3 Apr 2005 13:47:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33KltAk059016 for ; Sun, 3 Apr 2005 13:47:55 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1DIC0g-0007zs-00; Sun, 03 Apr 2005 21:47:54 +0100 Date: Sun, 3 Apr 2005 21:47:54 +0100 From: James Aylett To: Atom Syntax Subject: Re: Why is alternate link a MUST? Message-ID: <20050403204754.GD6334@tartarus.org> Mail-Followup-To: James Aylett , Atom Syntax References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f1451f5050403120638d8f259@mail.gmail.com> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Apr 03, 2005 at 03:06:26PM -0400, Joe Gregorio wrote: > I agree with Sam, +1 to the required . The argument that you > can't have an HTML representation are weak, since *I* can generate > one for your feed, whether you like it or not. Now the generated > HTML may not be optimal but I hope this shows that barrier to > generating an HTML 'alternate' is not onerous, and that the link > should remain a MUST. I think this highlights why I oppose MUST: what on earth is the utility of this alternate to the end user? The /only/ thing it seems to do is to provide a way of moving the view of the feed from the Atom client (which may be able to take advantage of the intrinsic structure, plus extension metadata) to an HTML client (probably a web browser), which probably can't do quite as much with it, and certainly can't do more in the case where the HTML is auto-generated from the Atom. Which, to the person sitting at the computer, doesn't strike me as much use. And since the spec doesn't touch user agent handling of the rel='alternate' (rightly), even if that were a desirable thing to do, it won't work with all feeds, since I am in my rights (for instance) to , an artistic interpretation of the feed as if it were a swallow. The spec doesn't tell us precisely enough what alternate is for it to make sense as a MUST, in my view. Further, I don't think that it is practical to try to get a precise enough wording for MUST to become useful; even if it was, it would probably require placing restrictions on how the Atom clients use the link, which we don't do at the moment and in IMHO we should not even consider. I think the argument that it is trivial to produce an HTML representation of the data in the Atom feed actually reinforces my point here - if the user agent actually NEEDS an HTML version of the data, and a link to one isn't supplied, it can generate one itself. It'll have to do that even with the current wording, since I can quite happily satisfy the MUST requirement with a non-HTML version. (Something which I believe can't be done legally with RSS, or at least not all the different breeds. Not that that matters.) James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Sun Apr 3 16:57:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25902 for ; Sun, 3 Apr 2005 16:57:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Kne7W059106; Sun, 3 Apr 2005 13:49:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33KneGh059105; Sun, 3 Apr 2005 13:49:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from home.fastolfe.net (postfix@adsl-65-71-209-3.dsl.stlsmo.swbell.net [65.71.209.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33KndQN059099 for ; Sun, 3 Apr 2005 13:49:39 -0700 (PDT) (envelope-from fastolfe@fastolfe.net) Received: by home.fastolfe.net (Postfix, from userid 1001) id 27E1116EDD; Sun, 3 Apr 2005 15:49:38 -0500 (CDT) Date: Sun, 3 Apr 2005 15:49:38 -0500 From: David Nesting To: Joe Gregorio Cc: Atom Syntax Subject: Re: Why is alternate link a MUST? Message-ID: <20050403204937.GO30546@home.fastolfe.net> References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f1451f5050403120638d8f259@mail.gmail.com> User-Agent: Mutt/1.4i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Apr 03, 2005 at 03:06:26PM -0400, Joe Gregorio wrote: > > I agree with Sam, +1 to the required . The argument that you > can't have an HTML representation are weak, since *I* can > generate one for your feed, whether you like it or not, ala: > > http://www.rss2html.com/ OK, I have Atom documents stored in the following places: 1. An attachment (or the content body) of an e-mail message 2. In an Oracle database behind a firewall 3. In an LDAP attribute, also behind a firewall 4. On a key chain hard drive 5. Typed out on a sheet of paper What URL can I use to refer to each of those? The key chain drive usually shows up as drive E:, if that helps. For simplicity, let's assume the sheet of paper can be stored on/in a flatbed scanner. > I can also generate an XSLT sheet that transforms Atom into > HTML then use the W3C XLST service to transform > an Atom feed into HTML: > > http://www.w3.org/2001/05/xslt Let's say I care about providing an HTML representation for my data. XML lets me embed an XML stylesheet into the XML data itself. So now I have a completely self-contained Atom resource that user agents can transform into HTML without needing a link to any external resource. Even if this could be represented with a URI, why would I want to specify an alternate version when the first version has everything I could want? All I hear are ways *some* Atom documents can be given alternate versions. I still haven't heard WHY that should be required, other than "because RSS does it." Why does RSS require it? Maybe we can start there. David -- == David Nesting WL7RO Fastolfe david@fastolfe.net http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01 From owner-atom-syntax@mail.imc.org Sun Apr 3 17:09:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26650 for ; Sun, 3 Apr 2005 17:09:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33L2kZk059910; Sun, 3 Apr 2005 14:02:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33L2kZ1059909; Sun, 3 Apr 2005 14:02:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33L2hE4059901 for ; Sun, 3 Apr 2005 14:02:44 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.54.76]) by smtp.cegetel.net (Postfix) with ESMTP id 3C133381AF; Sun, 3 Apr 2005 23:02:37 +0200 (CEST) Message-ID: <425059F2.6040709@cegetel.net> Date: Sun, 03 Apr 2005 23:02:42 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Henry Story Cc: Atom Syntax , atom-owl@googlegroups.com, bloged , Eric Scheid Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: > Perhaps you mean that they are alternate versions of the representations > described by the ? That's it! (I think...) Now that we agree, I let you use the web-arch to describe it. From owner-atom-syntax@mail.imc.org Sun Apr 3 17:29:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27762 for ; Sun, 3 Apr 2005 17:29:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33LN0Jr061431; Sun, 3 Apr 2005 14:23:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33LN0tr061430; Sun, 3 Apr 2005 14:23:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33LMx58061423 for ; Sun, 3 Apr 2005 14:22:59 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.8]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DICYU-0003F9-AI; Sun, 03 Apr 2005 21:22:50 +0000 Message-ID: <42505EA6.3030906@franklinmint.fm> Date: Sun, 03 Apr 2005 17:22:46 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst CC: David Nesting , Atom Syntax Subject: Re: Why is alternate link a MUST? References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <6.0.0.20.2.20050403101341.02fb0b20@itmail.it.aoyama.ac.jp> In-Reply-To: <6.0.0.20.2.20050403101341.02fb0b20@itmail.it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Martin Duerst wrote: > > Of course I'm also for making an alternate link for a feed a > MAY rather than a MUST. I'm in favor of keeping it a MUST, but I could live with it becoming a SHOULD. As Sam says, all versions of RSS have made it a requirement. Feeds without a link will probably break some clients, so you better know what you're doing. OTOH, there have been some persuasive arguments for making it optional. If we change it, SHOULD seems like the right way to go: "the distinction between 'SHOULD' and 'MUST' in RFC2119 doesn't apply to stupid implementors."[0] :) Robert Sayre [0] http://lists.w3.org/Archives/Public/ietf-http-wg/2005JanMar/0088.html From owner-atom-syntax@mail.imc.org Sun Apr 3 18:02:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29911 for ; Sun, 3 Apr 2005 18:02:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33LuAdG064480; Sun, 3 Apr 2005 14:56:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33LuAIk064479; Sun, 3 Apr 2005 14:56:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33LuAFC064473 for ; Sun, 3 Apr 2005 14:56:10 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 80867 invoked by uid 17064); 3 Apr 2005 21:56:08 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.132.105]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 3 Apr 2005 21:56:08 -0000 In-Reply-To: <425059F2.6040709@cegetel.net> References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <425059F2.6040709@cegetel.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/mixed; boundary=Apple-Mail-74--1033306506 Message-Id: Cc: Atom Syntax , atom-owl@googlegroups.com, bloged , Eric Scheid From: Henry Story Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state Date: Sun, 3 Apr 2005 23:56:03 +0200 To: Thomas Broyer X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-74--1033306506 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 3 Apr 2005, at 23:02, Thomas Broyer wrote: > Henry Story wrote: >> Perhaps you mean that they are alternate versions of the >> representations described by the ? > > That's it! (I think...) > > Now that we agree, I let you use the web-arch to describe it. Ok. So let us try the slightly clumsy (to be improved later) definition What about: [[ The value "alternate" signifies that the IRI in the value of the href attribute identifies a resource whose representations are an alternate version of the representation described by the resource described by the containing element. ]] --Apple-Mail-74--1033306506 Content-Type: image/jpeg; x-mac-hide-extension=yes; x-unix-mode=0644; name="Atom-related.jpg" Content-Disposition: inline; filename=Atom-related.jpg Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAFsAjEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKQsB1oAWiozMg70ecnq KAJKKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUUolU9DQA+ikBzS0AFFJSG RR1NADqKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUUecnqKAJKKj85PUU4O D0NADqKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigBK5nxpcldBuIwSN5RDg4yC4BH 4iumPSuL8cMf7NYf9NI//Q1pPYDR/wCER0P/AKB0P6/40f8ACIaH/wBA2H9f8a2abLLHBE8szrHG ilmdjgKByST2FedzS7iMj/hEND/6BsP6/wCNH/CIaH/0DYf1/wAaz9a8VSNoV9c6NbXTxxW7yC+M YWMEKSNofl8nHQEe9NvPE+qRyC2XTYYLtLq2R0e43KYpWIByF4OVII7dcmq9/uBpf8Ihof8A0DYf 1/xo/wCEQ0P/AKBsP6/41nx+Lr+4uIYrbRN4uZJ4oGa6ChmiYhi3ynaDg4PJzxjvRYeKLq9uZLmC yuLm0eztZxBHs8yLzPNLHkjd91RjPbij3+4Gh/wiGh/9A2H9f8aP+EQ0P/oGw/r/AI1d07VrPVUk NpKWaIhZY3UpJGfRlYAr+Iq5U80u4GN/wiGh/wDQNh/X/GszxH4f0vTNDnvLOzSG4hKMkiEgqd68 jmusrD8a/wDIpX/+6v8A6GtVGT5lqBu2c/nIDVqsnRWzAufStavQGRzPsQmuHns7XWvFmoi9iEyw 28AQMThcmXOPrgflXaXpxAa4vSDnxVrOf+eNv/OWsqztB2E9ix/wi2jf8+EX5n/Gj/hFtG/58Ivz P+Na1Ub/AFi0050imZ3uJATHBEheRwO4Uc49zx71xc0n1M9Sv/wi2jf8+EX5n/Gj/hFtG/58IvzP +NZd14l1O01C7kbTJPs8Fil08EkyK0ah5NxyM5Yqo+XOOOoqQeJL+O+u4fsMc4OoJaWoSbbwYBLl sr07/wDAiOcc17/cepof8Ito3/PhF+Z/xo/4RbRv+fCL8z/jWRP4uu5NKuZRYGzZra6MEplVyJYQ d2VxjGQcHvjkCtX/AISGOzONVgms4+Nty4BhcdiXHCf8CxS9/uGo7/hFtG/58IvzP+NH/CLaN/z4 Rfmf8a1qKnml3Fcyf+EW0b/nwi/M/wCNJoCQ6X4m1K0tU8uAwW7iME4DEyZP1OB+QrXrCt2I8cXo /wCnW3/9ClrahJuerKjudyh3KDTqjg5iFSV2lhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFcUPiJ/olnLLY29tJeRG4iS7 v0iBiGOdxH3iSQq9wMkiu1rl30XT7W403TrPVLy1vra1MCGAK8jQcffBQhRlRhsDnp6UAMfxs0kU l1Zaa09jBZw300zTBCsUgZuFwcsApOMj60XnjcWaXcktkkcEV39ihmluVjSWXr1I+VQuSWPpgA06 bwg15qd8Jry7j0+e1gtmjWRWNwqbwwcsC3cDIIJyea0J/DVtLbSRpPcRSNdm9jmQruil9VyCMYyM EHgmgDIb4gQtZQSQQWryySywsWvVWDem07VlwQxYMCoOM85xiutifzIkcqVLKDtOMj24rGm8Mme0 SF9W1Ek+YJnZo384PjIKspUYwMYAxz6nOta20dnaQ20IIihRY0BOTgDA5/CgCasia58QLPILfS9L eIMQjSajIjMueCQIDg+2T9a16KAMX7X4k/6BGk/hqkn/AMYo+1+JD00jSh9dTk/+MVtUUAeXfE4e MZLDTpbCNreYXBRU0u6lkdiyk/N8i8fKetZv2PxbBojSeKb6KTLRhINil0O9eWdePXjnr1r2I9K5 Txdp8t9p8scDKknDIzLkZBBGR6cUMDoaRlV1KuAysMEEZBFcFP4u8SQsR9k01v8AgMn+NRf8Jr4k /wCfLTvyk/xrh9hMR09x4R0+WCaC3e4s7edGSWC3kxEwYEcIQVU85yoHTnPSp77w9b313NcmaeKa QwHchX5DCzMpAIPdjnOfwrkf+E18Sf8APlp35Sf40f8ACa+JP+fLTvyk/wAafsqgzsLbQLa1ktHj eYm1kmkTcRyZWLNnj1Jx/Wqlt4RtbSFYYLy/jjEMUDBJQhdI920FlAIzvOcEdB05zzX/AAmviT/n y078pP8AGj/hNfEn/Plp35Sf40eyqAdra6Pa6f5QsE+yxo5d0iAAmJBHzkjJ65znOR1qW2s3tzGW vLmfZEIyJSvznP3zhR83049q4X/hNfEn/Plp35Sf40f8Jr4k/wCfLTvyk/xo9jMD0OsPxr/yKN// ALq/+hrXMf8ACa+JP+fLTvyk/wAaLnVdf8Q2L2NxFYQwzFQ7IjlgAwJxk9eKI0Zppgdvon+oX6Vr 1m6TGY4VB9K0q7QK17/qDXF6P/yNWs/9cbf+ctdtdruhIrz7UV1TSdZu7zTxbOtxHGrLMrZBQt0I P+1+lZ1YuUWkJ7HVVUvtLs9SC/a4Fdk+5IMq6e6sOV/A1yR8U+IgcfZNP/J/8aP+Eq8Rf8+mn/k/ +NcvsJkcrOh/4R2BorxJbq7l+12v2R2kcFgmXxg46/OeTnoKcnh63S/+1CafP2hLkR5XbvWIxZ6Z 5XGRnqB05zzn/CVeIv8An00/8n/xo/4SrxF/z6af+T/40/Y1B2ZvzeF7OazW2aS4CAXAyGGf327f 27bjj+tTf8I/ZyT+beeZeMpyi3Dbkj9NqfdGPXGfeua/4SrxF/z6af8Ak/8AjR/wlXiL/n00/wDJ /wDGj2NQLM64WbhgftlycM7YJXB3dB93ovb9c1PDGYYI42keUooUu+NzYHU4AGT9K4r/AISrxF/z 6af+T/40f8JV4i/59NP/ACf/ABpewmLlZ3Fcfq+sDQvE1/etZ3V0iW1vuS2QMyjMvzEEjjjrUCeJ /ETtj7Lp4/B/8a1vD9vfXOrz6hf+SJJY44wkKkABSxzyf9r9K0pUpRldlJNMzPD3xotdX1+DT5LB LGzYMZLu4uQAgCkjIxgZIA6969ItNTsb9c2V5bXAPeGVX/kaz7HwrpFlrbaza2UcN9JGY3eP5QwJ BJK9M8detWbvw/pF+2680uxnb1kt0Y/mRXUUaNFYv/CJaUv/AB7pdWvp9mvJogPwVgKP+Eenj/49 te1aH2Lxyj/yIjGgDaorF/s/Xov9TrkEn/XzYhv/AEB0o3eJYv4NIuf+BywZ/R6ANqis6wu9TmnM d/psVsoXIkiuRKpPpyqn9O1VLrxZZWl5fW8kN2TY7FldYsqXcLsRTnlmLgAevXHGQDcorn28YWqm OI2N/wDbHnNv9jEa+aH2eZg/NtwV5znHvSp4xsHlgjEV3mWJ5nzHgQKjFXMhz8u1gQf0zQBv0Vz6 +MrH7NJLPb3lviNJY0mjCtMjsEUrzjliB82CMjOK1tOvv7QtfNNtcWzBijRToFdSPoSD9QSKALVF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUVQ1jUxpdkHSPzrmVx Fbwg4Msh6DPYdST2AJ7UAV9X1O4FwumaSEfUZV3l3GUto848x/XvtX+IjsASLOl6TBpMDJFuklkO +aeQ5kmf+8x/p0A4AApmjaWdNt3aeQT3tw3m3U+Mb39B6KBwB2A9cmtGgAooooAKKKKACiiigAoo ooAKrXFsJhgirNFAGJJocbnO0Uz/AIR+P+4PyreooAwf+Efj/uD8qP8AhH4/7g/Kt6igDB/4R+P+ 4Pyo/wCEfj/uD8q3qKAMH/hH4/7g/Kj/AIR+P+4PyreooAwf+Efj/uD8qng0eOIghRWvRQBHFEI1 wKkoooAay7his+50xJzytaVFAGCdAjJ+6KP+Efj/ALg/Kt6igDB/4R+P+4Pyo/4R+P8AuD8q3qKA MH/hH4/7g/Kj/hH4/wC4PyreooAwf+Efj/uD8qP+Efj/ALg/Kt6igDCXQYwc7RV+209YOgq9RQAg GBS0UUAFFFFABRRRQAVz+p+FI9TttViknQ/b7iK5UPCHWNo1jADKT86kx8jjIJHvXQUUAcX/AMIt fadeaY+nHT4ZhdyTSNb2AjgjXyWUAorBjn1LZyfTitC08Hxwxzpc3bTi6tZoLghNpdpZGd2HJxy5 AHOOOa6SigDkbLwQ9nZ3EaSaSkrwrCpi0pFR1DAnzQSS+7GCAQO455G14f0c6Hp7W3mIwaRpAkaF I4gcfKiknCjHTPc9OlalFAFPULyeyjSSGwnvATh1gZNyj1wxGfwOfaoLLxFp19cC2Wcw3Z/5drlD DL+CsASPcZFadVr7T7TU7cwX1tFcRHnbIoYA+o9D70AWaK57Nx4ZuoVeeW50eZ1iDTMXktHYgJ8x 5ZCTjnJUkckfd6GgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigBKwtIH9t6k2t yc2yBodPXtsz80v1cjj/AGQP7xp3iCR76WDQ7Zysl4C1w6nBitx9857FshB9Sf4a2Yo0hiSOJFSN FCqqjAAHQCgB9FFFABWFrN1fjxDpVnZXPkQyxTzTgRh2cRmPCjPTO4j6E98Y0NS1e00mNGupCHkO 2KJFLySt6Ko5J+lNsHmvWW6vNNW1kUFYfMdXlVTjIOBhc4HAY9BQBwieLfEA0JtScmMXOnSXaeeL cJEw2lfLCuXZRuwdwz06dK1L3U9YtNQfSoNVWaVpbTF09un7sSmQMu0YBx5YYd+eSe+9eeFtMuLK /gt7S3tXvkKTTQwqGbJyc8c881bttG02yjEdrp9pCgkEoWOFVG8dG4HX3oA5S21/Wn1ok+a1pHqJ sWEn2dImVflLZLCTzD97AGMcAd6v+FdV1C6vWh1S4dpZbcTomyMxMM4LwyIfmQ5HDfNyK3f7I0/+ 0v7R+w2323GPtHlL5nTH3sZ6cUWWkafpryPY2NtbNIcuYolUt35x7k/nQBbzjrS1FcW0N3byQXMS SwyLtdHXKsPQisn/AIR2Sz50bU7qzx0hkP2iH/vlzkD2VloA26a8ixqWdgABkk9q8z+JXjHxJ4U0 2xCmyiuJLjcJoGLCVFB3KY3X5RyvIY/WqkXj2Xxd4VuIL/SZ7WVggdzGTBKN6ggE+ufunPHc0Aen HVLIf8vUP/fwUn9q2X/P1D/32Kzv+Eb0X/oEaf8A+Ayf4Uf8I3ov/QH0/wD8Bk/wrm+srsBo/wBq 2X/P1D/32KP7Vsv+fqH/AL7FZ3/CN6L/ANAfT/8AwGT/AAo/4RvRf+gPp/8A4DJ/hR9ZXYDR/tWy /wCfqH/vsUf2rZf8/UP/AH2Kzv8AhG9F/wCgPp//AIDJ/hR/wjei/wDQH0//AMBk/wAKPrK7AaP9 q2X/AD9Q/wDfYo/tWy/5+of++xWd/wAI3ov/AEB9P/8AAZP8KP8AhG9F/wCgPp//AIDJ/hR9ZXYD R/tWy/5+of8AvsU5NRtJGCrcREk4ADjmsz/hG9F/6A+n/wDgMn+FZHirRNKtPDtzPb6ZZRSxlGV0 t0VlIdeQQOKaxCbtYDswQelLVSxn86MGrddACVDNeW8BAlmjQnnDMBT532Rk1w5tLPVfF+qNeWlv cGO2t1Uyxq+3mXpkVM5csbibsdh/atl/z9Q/99ij+1bL/n6h/wC+xXO/8I/pH/QKsP8AwHT/AAo/ 4R/SP+gVYf8AgOn+FYfWV2FzHRf2rZf8/UP/AH2KP7Vsv+fqH/vsVzv/AAj+kf8AQKsP/AdP8KP+ Ef0j/oFWH/gOn+FH1ldg5jov7Vsv+fqH/vsUf2rZf8/UP/fYrnf+Ef0j/oFWH/gOn+FH/CP6R/0C rD/wHT/Cj6yuwcx0X9q2X/P1D/32KP7Vsv8An6h/77Fc7/wj+kf9Aqw/8B0/wo/4R/SP+gVYf+A6 f4UfWV2DmOi/tWy/5+of++xU8NzDOCYpEcDglSDXLf8ACP6R/wBAqw/8B0/wrFbWtI8E63qlxOkd rbPBbAJBFje/77gAdyB39KuFZTdrApXPSKK8o8O/GG58QeMRYQaS7WbxOIYYypndxzklmVQMA8fq a7z7T4hu/wDU2NlYIf47mYzOP+AJgf8Aj9bFG3Uc7FLeRl6qpI/Ksj+wbq651PWr6YHrFbEWyfgU +f8A8fNaNlp1rp9r9ntYgkRJJBJYsT1JJyT+NAHERa34hktNIh+0zyz3mnnUJJbaG3BXhAEAkZRt G4lj1ORjaKePEesS2t7qMl9FB9igtJjZxJHIsrSIpZd/OQSSFKnr3IrsLrRNMvreC3u9OtJobcAQ xyQqyxgDGFGOBjjiqyeGtO/tibUprWCad2Ro2kiUmHaoUbTjI6ZoA5u41vXEjylxJL9s1aaxhWCG IPDHGZTkFyFLnYB8xxjsT1bPr2u/2dG7SvF5AuDO9uLeWYBHAR5IwxG0DIcIc7hxiuyn0uwubR7W eyt5LeRzI8TRgqzE7ixHrnnPrzUMvh/SJ4LeGXTLJ4rYEQo0ClYweoUY4FAF6GQTQpIrBldQwI6E Gn1n6vqMmk2q3f2czW0bZuCp+aKPu4GPmx1I64yRnGDeR1kRXRgysMgg5BFADqKKKACiiigDE8Y4 PhLUox/rJovJi/66OQqf+PFa26wZm/tvxFHAnNlpbiSZu0lxj5E/4ADuPuU9DW9QAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABUN3dQ2NpNdXMgjghQvI56KoGSamrAvT/AG7raacnzWNi 6zXh7SS8NHF744dv+ADuaAJ/D9rMY59Uvoyl7fkOyN1hjH+rj/AEk/7TNWxRVHU9YtdKRPtDM00p xDBEu+WU+iqOT9eg7kUAXSQBk8CsJ9ZudXdoPDyo0YO2TUJRmFPXYP8Alo30wo7ntSf2Xe66d+u4 hs+q6bG+Q3/XZh97/dHy+u6t1EWNFSNQqKMKqjAA9BQBn6boltpsj3GZLm9kGJbuc7pHHpnoq/7K gD2rSoooAKKKKACiiigAooooAZJFHIVZ0VihypIzg+1cZ44J/s5v+ukf/oa12p6GuK8cf8g5v+us f/oa0nsB1dZet+ILbQltxOkkkty5SGNcLub0LMQq/iRntmtSmSxRzxNFNGskbDDI4yCPcV5q8xHL 6v4k1fRltWu7OxU30ht7eNZyTHK2PLLscZX727A44wTmootW1ez1O/dnt5bIarFaFX3lx5iRLlOc KoZgcc5yenfY/wCET0bZIn2JTG8bxeWXYoitjcEXOEztH3cdKtDRbERsnkkh7hLlsyMSZE27WyTn jYv1xz1NXzRA5Oz8Qa+mnxIHsZ5vIu7p5ZY3HEUoUKAG75PPYY645lm1/VLgQw3PkwSSSafcxm3L DCSzbTGxz833cEjAIJ4ro4fD2mwF/LgYb0ljIMrkBZGDOACeASAeOnbFK+gadI6M1v8AMiRIpEjD AiYtH37Ek+/fNHNHsBSi8SPaanb6ZrNssF3cHbC1vIJY5Pw4dfxXA9a3qpWWj2GnRSJaWyReZ/rH GS7+7OfmJ9yc0HSLQxeXifb5SQ/8fEmdqHK87s555PU9yal2Au1h+Nf+RSv/APdX/wBDWtysPxr/ AMijf/7q/wDoa0Q+JAaOinMC/StasjRP9Qv0rXr0hla9OIDXGaQc+KtZ/wCuNv8Azlrs73/UGuL0 f/katZ/642/85ayr/AxS2N+sODxBJqt1LBo9ujrBJsmmuJNgQg84QfOT9Qo963Kp3elWV9Mk1xbq Zo/uSqSsi/Rhgge2a4VbqZnLT+I9R1HTL1YlhhnsbmC2kMchG+bz1BwQciMr68/MR2Obbarq76vZ Wck1qjxan9nnMcbbZkNs0o4LZHcd+QD0yDrp4b0uNUVLUKEREGHYZCOHXPPJDDOTk8n1OZZNHspb jz2ibzfPW53rIwPmKmwHg/3eCOhGc9armj2Gc1D4k16e1t5Vi01ftFg98uQ52hNuVPPJO4c9uetX LLVdRluNRuraFLiASxs0Mk+xkUwRN8hI29SSQcDnrWxHolhFFFGkGEitmtUG9uIjjK9f9kc9eKjP hzS2I32iuuQxR2ZkJCqoJUnBwFUDI7e5o5o9gJNH1m21yzNzab9quY2DDow6jIyD16gke9X6ry2U EzKWVhsjaNQjsoCtjPAIHYYPUdsU6C0it5GePfuZFQ7pGbhc44J68nnqe+ah2ETVgw8+N70HkG1g yP8AgUtb1YMP/I83v/Xrb/8AoUlbYf4yo7nT2nh/SIryO/i0yzjvEztnSBVcZGDyBnoSPxrVqKD/ AFQqWu4sKKKKACiiigAooooAQgEEEZB6isPQs6VfXGhOT5US+fZE/wDPAnBT/gDcf7pSt2sbxHby rbwanaIz3WnP5wReskZGJEH1XkD+8q0AbNFRW9xFd20VxbuskMqB0dejKRkEfhUtABWTreozQmLT 9O2nUrvIiyMiFB96Vh6LkcdyQO/FzU9Qh0rT5by43FIx91RlnYnCqo7kkgAepqnomnTW4lvtQ2nU rzDTYOREo+7Ep/urn8SSe9AFvTdOh0qwjtLfcUTJLMcs7E5ZmPckkkn1NW6KKACiiigAooooAKKK KACiiigAoopCcCgBHcIMmsGTxJLdTyRaLYyX3lsVecuI4VYdRvPLEf7IOOhxUPiW5luHtdKtpXik v5vKaRDhkjALOQex2qQD2LCta2tobK1itraJYoYlCIiDAUDoBWNWryaLcDN+3+Jf+gVpn/gxf/4z R9u8S/8AQL0z/wAGL/8AxmteoWvIFvksy/8ApDxtKqYPKqQCc9OrD86w9vMRnfbvEv8A0C9M/wDB i/8A8Zo+3eJf+gXpn/gxf/4zWvUN5eQWFq9xcvsiTG5sE4ycDge5o9vMZlT3nipoJFg07So5SpCO 1/IwU9iR5Iz9M1X0uPxDpVgltFpmnORlnkfUX3SuTlnb9z1JJNb81zDbmITSKhlcRpn+JiCcD8jU lHt5iMC+uvF81sUsrLSbeU/8tWvXk2jvgeUOfTOR7Gq2ny3Hh1pLnUtIlkeQfv8AUIp/tTkf7Xyq wX2VcD0FdFFeQTXU9vG+ZYNvmLg/LuGRz34qaj281uMktbuG7gSaCRZI5FDI6nIYHoQanrkrJF8P +JH0+BRHY3kbXMEYGFjcMBIoHYHcrY9S1dWjblBrrjJSV0A6iiiqAKKKKACiiigAooooAQ9K5fxV pz39jJEjbGOCrYzgggjjvyK6moJ7cSjBFAHnFx4g8UwuQLizb/t1P/xdQ/8ACT+K/wDntZf+Ap/+ KrvZNFjc5Kimf2FF/dFR7OHYDhf+En8V/wDPay/8BT/8VR/wk/iv/ntZf+Ap/wDiq7r+wov7oo/s KL+6KPZw7AcL/wAJP4r/AOe1l/4Cn/4qj/hJ/Ff/AD2sv/AU/wDxVd1/YUX90Uf2FF/dFHs4dgOF /wCEn8V/89rL/wABT/8AFUf8JP4r/wCe1l/4Cn/4qu6/sKL+6KP7Ci/uij2cOwHC/wDCT+K/+e1l /wCAp/8Aiqke58Qa9atZ3t1bLbylfM8u2wxAIOAS3HT0rtv7Ci/uipodJjiOQoo9nFdAHaVEY4VB 9K0qjjjEYwKkqwILpd0JFef6pbanp2rXN5ptxGnnoiOkkO/7pbBByP7xr0Vl3DFUrjTkmPIpNJqz A81Ot+Jwcedaf+Ax/wDiqT+3PE//AD2tP/AY/wDxVegHQos/dFH9hRf3RUeyh2FZHn/9ueJ/+e1p /wCAx/8AiqP7c8T/APPa0/8AAY//ABVegf2FF/dFH9hRf3RR7KHYLI8//tzxP/z2tP8AwGP/AMVR /bnif/ntaf8AgMf/AIqvQP7Ci/uij+wov7oo9lDsFkef/wBueJ/+e1p/4DH/AOKo/tzxP/z2tP8A wGP/AMVXoH9hRf3RR/YUX90Ueyh2CyOBTWvEzNgz2g/7dj/8VW34esryTU5r+/mSSaVEj+SPYAFL EcZPPzGukXQ4gfuirlvYrD0FUoRTukFi1EMRgU+kAwKWqGFFFNdtq5NAAWC9ayL/AMVaXp85t5Ln zLgcmCBGlkH1VASPyrK1S+udZ1STTLOZ4LWAD7XPGcOSRkRIexIOS3UAjHJyLFnY22nQCGzgSGMc 4UYyfU+p9zWFSsoOyJcrDj4wU/c0nVWHr9n2/wAyDSf8Jef+gPqv/flf/iqnqOa5ht9vnzRx7shd 7AZwCTjPsCfoDWX1iXYXMxn/AAl5/wCgPqv/AH5X/wCKo/4S8/8AQH1X/vyv/wAVUyOsiK6MGVhk MDkEetNmmjt4XlmkSONBuZ3YAKPUk9KPrEuwczMjSNfn0qW5tU0fU208t5lt+6XdFuJLR43fdB5H scdhnT/4S8/9AfVf+/K//FVPRR9Zl2DmMa81+a+1qzlm0fU/sVoDKq+UuXmPCkjd0Ubj9WB7Vpf8 Jef+gPqv/flf/iqnqE3duLZ7gzxCBN26TeNq7SQ2T0GCCD9KPrEuwczE/wCEvP8A0B9V/wC/K/8A xVH/AAl5/wCgPqv/AH5X/wCKqZmVMbmAycDJ6mlo+sy7BzEH/CXn/oD6r/35X/4qnDxjCnM+napC vdjaM+P++M05Zo2meJZEMiAMyBhlQc4JHbOD+Rp9H1mXYOYu6brun6srGyuopinDqp+ZD6MvUH61 oA56VymoaRb37LKd0N3GP3V1Cdskf0PcexyD3FW/D2sT3DTWOo7BfWpAkKDCyqc7ZFHYHB47EEc4 yd6dVT06lJ3OhopAcilrUYUUUUAFMk4Q0+msMqRQBxt9MIvGWjvJ9xnlhBPZmQkf+g4/GuprlvFe mNdQHYzI6sHjdeqOpyrD3BANM0jx1aeUtvr7pYXqDDSOCIZf9pW6Ln+6xBHTnrXLXg2+ZAWPG0Fz cWNisQ3WougbtTbvODHsbG6NCGZd+3IB9zwDWBHpt2LJQ4vzAbK6VXjs2Vo1aeIqojLFtuASEJ3F RjA6V1n/AAl3h7/oPaV/4GR/40f8Jd4e/wCg9pX/AIGR/wCNYpyStYRxklndGztEazji0uO6lMgX T55IZCY02P8AZ9wdVzvGOV3c981s3FvcyeAhpckd9NctArZMDo23zRgdWwwXHG4nAya2v+Eu8Pf9 B7Sv/AyP/Gj/AIS7w9/0HtK/8DI/8abb7Ac3d6BFa6vsi0x/sEOo28yKsLOq5jYOyjB/i25I78mo LLwpFN/Zhu9PnbzLW7N1vD/M+9PLD/QFtoPTHHSur/4S7w9/0HtK/wDAyP8Axo/4S7w9/wBB7Sv/ AAMj/wAaOaQFDwdBeRiWS+inSWS0s9zSqQWcRDd17g9feumrI/4S7w9/0HtK/wDAyP8AxqnqPj7Q bG3d4b2O/kAJEVmwlJx6kfKv1JFS1KT2Aj16UN4u0iJD88UE8j+wYoB+eD/3zXV2pzCM15TovivS p9Sn1LVdXtBdXBGQH+WNBnag9hk89ySe9er2pVrdGRgysAQQcgiu6nHlikMmoooqwCiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKqX8hSEkelW6q3sfmQkUAcj4ZkDrqSn/AFq30hk9ecFf/HStbVcjqQvNC1htRsk8xXAW4gJw JVHQg9mHOD36HsRsaZ4m0vVcJBcrHP3t5vkkH/AT1+oyPeuGtTak30IkjWrzue9827tZW1KZ9RE1 4ZrYy5EBWKYLhf4cDGP72c816JSYAJIAyetZxlYk4q21GUa5Z+ZfPKWMCCGO5Kum6Nc7oSMOpJLb xyOfQ1kpqJufCqmLUp76a40eV75JJi4iYKu0kfwnJI7ZGTzjNel7Ru3YGcYzUFhZQ6dYQWluCIoI 1jTJycKMDJ+gquddh3OQutZlTxSnkXJU/bvs7RS3Z5GwgDyQMBS2CHJySR6iq39pzJ4f+02erXE1 +8EZv0eUlbdmkQSEnB8oqC4wBwATj5a7/AznApcDnjrS512C5wcN/IUiju9WWLSmvShuIb55NuIs iMzsq5BbnIJ5+XPanxXMTfDW+txc75nivJFL/fdRM4LkfUj867jYu3btG30xxS0c/kFzhtVt/s99 LaT3129rBc2M++W5bKF3dWO7PA+UHHQHpinWdvc3t3YebqmoBbue8SVUuCo2o7bAuPu4wORyenTi u3oo5wucr4OuZbyd7i4cyTSabZM7nqx/e5JrqqKRmCKWYgKOSSeBUyd3cQtYyygeOFEfVLECXHu/ yfyf86r6l4xsbctBpxGoXnQJC2UQ/wC2/QfTk+1P8LadOJZLq7cy3Vw++WTGMnsAOygcAeldFCm7 8zKijuIjmMGpKZENqAU+ussKKKKACiiigCpeWizoQRXLaj4ZWZiQtdpTTGrdRQB5s3g8Z+4Pypv/ AAh4/uD8q9I8hPSj7PH6UAeb/wDCHj+4Pyp0XhWO3lSWSMFUYHBFejfZ4/Sqep2TzQKlugJLZJyB gVMtnYDg/wDhE4pGYxKNueBjpR/wh4/uD8q7HSLKUO0hKeXkqy98itf7PH6UoNuOoHm48Hj+4Pyr QsfCqxsCV/Su48hPSnCJR0FWB5ZrXwXtNT1q0vLGVbWBpQbyHHBXqSnox6Y6c57YPdCHX9MAEM1t qsC/wTjyJgP95RsY+21frW30paAMVPFNlG6xamk+lzE4C3qbFJ9BICUP0DZrZVgyhlIIIyCO9UtX 1PT9LtFfVJUjgmkWAb1LBmboMAH39sdapN4XtYGL6RPcaU5OcWrARE+8TAp+IAPvQBt0VnQ3E2nr bxateQTTXEvkwtFA0e5trNgjc3OFJzwOKuW1zDeWsVzbSLJBMgkjdejKRkEfhQBLRRRQAUVELmE3 ZthIvnhBIU77ScZ/MGpaACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKRl3DBpaKAMbUtKW5U/KK4/U/B8VxkSQo6+jKCK9IIB61G0CN1FAHkv/ AAhCJwkZQeisQP0pP+EL9pP++2/xr1c2UZ7CquoPZaXZvc3bBI1wOBlmJ4CqBySTwAOTRYDx/wAQ 6GdC0eW/FrNcLGRuCykbQe556fT1rD8Iaff+Kbua5KmKyg+UqhbDsegyTngc/lXtVnoUuqzrf6zE I0U5trAkFYvRpOzSfovbJ5rQ03w5p2j2n2bT7ZIId7PsXpknJ/z26dKVgPMz4NCgkhwBySZG/wAa r2nhqG8Z1h8w7O+9uf1r1q70m3urWSGXIRhglTg/nWT4d8ORWkS3ayOwuIgfLYdAeRz9Kl35lYl3 ujhP+EL9pP8Avtv8aP8AhC/aT/vtv8a9W+wxego+wxegqrFHlP8AwhftJ/323+NH/CF+0n/fbf41 6t9hi9BR9hi9BRYDyn/hC/aT/vtv8aengaJ2BkgEmP7/AM3869U+wxegpRZxjsKdgOM0rwskG3CA AdABXW2VktugAFW1iVegp1ABS0UUAFFFFABRRRQAUUUUAFFFFABRRRQBS0/5ZLtPSYn86u1Ss+NQ vV/2lP5irtTHYAoooqgCiiigDkvE+k3/AIj1cWUCwx2dvaPvkuYWZHeYFPlwR8yqG57eZTJZ7ifw sst3pt3JrAsHglAjlUHDqknI9SNwA+Yr0rsKKAPOdK06eS+S1azdrEamkoVLCS3h8trWRGIRs4Xd wcnqc/xDOUmkXa6RpsEltPBHHpEUVun9mTSvFdAsJSu1kEcm7aQ7cHqDjOfW6KAOBn8PS3DahNc2 91LcTataxtJhgWgHkFyoHRSQ2SPQ88VHd6a1oJ9OXTSNOGpyPCJLSW4hjXyYyMRIRuBdnxztBB74 r0KigDy1dM1FtKWWOyul1JtHSAytbv5mUmIkXPB3eX0GQW7E9a6nwVaNbC/aPcto7p5Ua2L2kakL 8xRHdm54ycAZB6810d1DJcW7RxXEts56SxhSy/TcCP0rI+2azpP/AB/2y6lbD/l4s12yqP8AaiJ5 +qEn/ZoA3aKqafqllqsJlsbhJlU7WA4ZD6Mp5U+xANW6ACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiis7XtSOk6HdXka75UTEKf35GO1F/FiB+NAFu3u7e7 V2tp4pljcxuY3DBWHBU46EdxU1cDoEE3hya+0vVtunW91YfaBPFc7jvjQJNJu2jDEFG6dQTTdR11 4fFUZgvWRYr+C3dJb0gmNlUEiADBU7s+Yxzk8dqAO7huYLlQ0E0cqkZBRwwIzjPHuDUteURzTadZ yXdlNIl4dK/dgzMAF+0sJGC8j5VO7ODjritG1uL29a3tIdXb7HNqUcQks797lgPIlZ085kXOSqnj O0ntxQB6NWPBpbtqB1TWJY3miyLeNT+6tl6EjOMue7Ed8DAznnbWa6tru01Br++lL6zd2rQtKWQw r5+1QncgoCD17ZxxXPz6o+o6TqMD3zyQXGlG5I/tBpn3q6klsACNtrfMi5AFAHrVFedDVL5/E7Rx ajErJfQw28T38hMlsQmSIQhEgZSx8wtwe4CmvRaAKerOY9KuShw5jKr9TwP1NWo0EcaoowqgAfSq mqfNHbxf89LiMfkd3/stXaXUXUKKKKYwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigClbcaree4Q/pV2qUH/IWuvdEq7Ux2AKKKKoAooooAKKKKACiiigAooooAKKKKAM3UdBs9RmFy Q9veKMJd27bJVHpn+If7LZHtVT7bq2jcajAdRtB/y9Wkf71R/txDr9Uz/uit2s3W9WGkaZNdCPzW QDam7buJIAGe3JoAs2OoWmp2wuLG4jniJxuRs4PcH0Pseas1xN9Zavd3RvLfSIbK+Ix9pttQ2s3o GHl7XHswNW7G/wDFkcOy+0ywmkH/AC1juygYe67Tg/j+VR7WHcDq6K5z+0vEP/QGtf8AwP8A/sKP 7S8Q/wDQGtf/AAP/APsKPaw7gdHRXOf2l4h/6A1r/wCB/wD9hR/aXiH/AKA1r/4H/wD2FHtYdwOj ornP7S8Q/wDQGtf/AAP/APsKP7S8Q/8AQGtf/A//AOwo9rDuB0dFc5/aXiH/AKA1r/4H/wD2FR3X iDWNOtzc3ukQLboyiRkvdzAEgZA2DPX1o9pF9QOnoqOOQSDIqSrAKKazbRmudv8AxHex6vNY6fp6 XJhiSSR3uPLxvLAADac/dNJtJXYHSUVy39u69/0Brb/wO/8AsKP7d17/AKA1t/4Hf/YVHtYdxXR1 NFct/buvf9Aa2/8AA7/7Cj+3de/6A1t/4Hf/AGFHtYdwujqaK5b+3de/6A1t/wCB3/2FH9u69/0B rb/wO/8AsKPaw7hdHU0Vy39u69/0Brb/AMDv/sKP7d17/oDW3/gd/wDYUe1h3C6Oporlv7d13/oD W3/gd/8AYVb0bX57+9urO9s1tZ7dI3ws3mBlfdjnA5+Q/pVKcW7Jhc3qKQHIoqhi0m0ZzgZrKufE 2l20xgS5Fzc/8+9opmk/FUyR9TgVXMWr63xcF9IsT1jjcG5kHoWGVjH+6Sf9oUAS32tSPdtp+jRJ dXy8Sux/c22e8hHf0Qcn2HNatvG0UCJIys4HzMq7QT3wOwqOysbbTbVLaygSGFOiIMfU+5Pc96sU AFJtA6AUtFACbV3A4GQMZxS0UUAUrv5tSsE9GeT8kK/+zVdqk/za5F/0zt3/APHmX/4mrtJCQUUU UxhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFKL/kL3H/XNau1Sj/5DM3vEP51 dqYgFFFFUAUUUUAFFFFABRRRQAUUUUAFFFFACHpXH+NpiNKdfWSMf+PrXYHoa4rxx/yDz/11j/8A Q1pPYDq6KKz9bTVJNOK6LJBHc7hky/3e4U4IDehII9q81CNCivPtTsp3S2D22ohRODqBv4XvFkGx /LO2NgGQNnhcAEqSoog8PSXtqUv7e6uUj0ybyPNhePaxlcxgLuYhguNoJ3AY6HNXyLuB3sdzDLNL DHIrSQkCRR1UkZGfwqSvPP7Ee5vHW4sLgSXVxZSTusTrvTy8PuYD+9nIz3561b+whPEFzpE0EraX Z+ZqIWIMSRIhRYwF5zuM5AHotHIu4HcUVy+mf2vYzyXDreDR0jJFvdn7RdE9tgTJx7MzN7Ct9r9F maMw3JKyrFkQsVJKg5Bxjbzgt0B4qWrAWaxPGZx4UvT6BP8A0Na26wvGv/Io3/8Aur/6GtEPiQGt pUpkhUn0rSrI0T/UL9K169IZBdNthJrjdNkMnivWCe0FuP1lrsL3/UGuL0f/AJGrWf8Arjb/AM5a yr/AxS2N+iiua1SDU3v5Wvxcz6Vn5I9PfYwHfzBw7f8AAG5/u1wpXMzpajuLiK1gead1jiQZZm6A VwtlY3n9sl3Eq3QuZmZlsZNzQYbYplL7Sm0rhQMggcZBNRz+Hmi0OKOLT5mabRc3KmNmLzKYiu4H +Pl8Dr27VXIr7jsehUVxculLDb6xq0VvLHNbXKXFsXVl/cxxxMVVTjAIDKff6U+G0nazhuLeDUhq 12GuTJDJsSMOxZVfdlDtGBjDEY6UcvmFjsaKzLO8urWyWPVVMt5HGHla1gcxtliAF45IxyPxwAav xTiZpQEkXy32HehUE4ByM9Rz1Hv6VDQiSuaezW88a3ivcXcSi1gysE7Rbvmk6lSD+tdLWDD/AMjz e/8AXrb/APoUlbYf4yo7m/F4U01owXbUHP8At6lct/N6f/wiGhn/AFunRTj0uC0o/Jya1YP9UKlr uLIba0t7OIRWsEUEY6JGgUD8BU1FFABRRRQAUUUUAFFFFAFKH5taum7LDEv45cn+Yq7VKx+a91B/ +myoPoEX+pNXaSEgooopjCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAKS8a0/v AD+tXapHjWx72+P/AB6rtTHqAUUUVQBRRRQAUUUUAFFFFABRRRQAUUUUAIelcT47Ij0qSR2Cojoz MTgABxkmu2rJ1WwF1EykAgjBBoAh/wCEk0X/AKDGnf8AgUn+NH/CSaJ/0GNO/wDApP8AGuUuvB8U jkiFP++RVf8A4QuP/nin/fNc31ZdwOz/AOEk0T/oMad/4FJ/jR/wkmif9BjTv/ApP8a8i8bR/wDC K28Rj0zzPO4E7L+7Q+h9/bj8eat+DPC02o+Ho9QvV3yXTGRQy42r0GB2HGfxo+rLuB6l/wAJJon/ AEGNO/8AApP8agt9Y8OW0s0sGp6Ysk7bpHFymXPuc1yf/CFx/wDPFP8Avms/SfCUcgvIjEpa3upE Py9M4cfo4o+rruB6H/wkmif9BjTv/ApP8aP+Ek0T/oMad/4FJ/jXGf8ACFx/88U/75o/4QuP/nin /fNH1ZdwOz/4STRP+gxp3/gUn+NY3i7XdKufDF5Db6nZSyvsVUS4RmY714AB5rF/4QuP/nin/fNa Om+FYreVW8lAQcg7RxTWHSd7gdTooxAv0rWqpYweTGBVuugCtejMBrg7LULPT/Feri8u7e3Lw25X zZFTdzJ0ya9BmTfGRXJ6z4fS9cs8asfUrmpnHmjYTVx3/CQaP/0FbD/wJT/Gj/hIdH/6Cth/4Ep/ jXPN4MjLf6lP++RSf8IXH/zxT/vmsPqy7i5Tov8AhIdH/wCgrYf+BKf40n/CQ6P/ANBaw/8AAlP8 a4y/8MB7tNNs40+0yLvkcKP3MfTcfc9APXJ7Gr8XgeGGJY0gQKowPlo+rLuHKb91qugX0BgutR06 WJuqNcJg/Xnke1Tf8JBo/wD0FbD/AMCU/wAa8pMlqnxGOisI/IKiAcDHm9fzydv1rtP+ELj/AOeK f980fVl3DlOi/wCEh0f/AKCth/4Ep/jR/wAJDo//AEFbD/wJT/Gud/4QuP8A54p/3zR/whcf/PFP ++aPqy7hynRf8JBo/wD0FbD/AMCU/wAazNOure+8Z3stpPFPGLaAFonDDOZO4qlH4MjDg+Sn/fIr p9F0VbIAIir64GKuFFQd7go2Ojg/1QqSmoNqgU6tigooooAKKKKACiiigAoopCQASegoAp6V81vN J/z0uJT+AcgfoBV2qWjgjSLUnq8Yc/Vuf61dpLYS2CiiimMKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooApS/LrFuf70bD+tXapXny31k/+0y/mKu1Md2AUUUVQBRRRQAUUUUAFFFFA BRRRQAUUUUAFNKhuop1NZlRCzsFVRkknAAoAYYEPUVkXuqxLdPY6Xb/b79eHRW2xw+8j8hfpyx7C ohcXnibP2KWSy0g/8vK8TXQ/6Z/3E/2+p/hxwx2bGxttNtUtrKBIYU6Kg/Mn1J7k8mgDGj8JW14J Jtf8vUbmZDGQyYiiU9VjX+H3bO44HPAA17XTraztYra3iWOGFBGiDoqgYAq1RQBF9nj/ALtYumwJ D4p1q3xxItvdD/gStH/7RFb9Ysv7jxvbHtdafKp+sciED8pG/I0Aav2eP+7R9nj/ALtS0UARfZ4/ 7tKIUHQVJRQAgAHSloooASmtErdRT6KAIvs8f92s/WLyLS7VTHD593O3lW0AODLIegz2A5JPYAmr t7ewadZS3d3II4Il3Ox/zyfbvWbo9lPcXTaxqcZS7lXZBA3/AC6xddv++cAsfXA6KKAJdH0RdOtn adxPe3DeZcz4xvf2HZQOAOwH1NaH2eP+7UtFAHn158O/D0XjiyuZLSQ/bDPKW89wftAZXU5B9PMO Pau8+zx/3ayfFX7jS49RH3tNuEuifRAdsn/kNnraoAj+zx/3aPs8f92paKAIvs8fpTljVegp9FAB RRRQAUUUUAFFFFABRRRQAVU1SQxaVdMv3vKYL9SMD9at1R1T54oIf+e06L+AO4/oppPYT2LcUYih SNeiKFH4U+iimMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAKWqfLDFJ/ zzlVqu1W1CPzbCZe+3P5c1JbSedbRSf3lBqV8QEtFFFUAUUUUAFFFFABRRRQAUUUUAFFFFABWBqC f8JBq76WSf7OtArXoB/17nlYT/s4+Zh3BUdCa36xfCo36bczn/WT390zn6TOg/JUUfhQBsgAAADA HaloooAKKKKACsXW/wBzrGhXPYXbwMf9l4nx/wCPKlbVYvi393oRue9pcQXOfQJKrN/46GH40AbV FFFABRRRQAUUUUAFJS1la1Z3WpiKwjJispSTdyhsMUH/ACzXvluhPYZ7kYAKdqP+Em1FL5+dKtHz aL2uJR/y1Pqq9F9Tlv7proaZHGkMSRxIqIgCqqjAUDoAKfQAUUUUAQ3VtHeWk1tMMxzI0bj1BGDV DwvcSXXhqwec5mWIRSn1dPkb9VNatYvhj5LW/hH3YtQuQP8AgUhf/wBmoA2qKKKACiiigAooooAK KKKACiiigAooooAKozfvdYtk7QxtKfqflX9N9Xqo2P767vLnsXEKf7qcH/x4tSYmXqKKKYwooooA KKKKACiiigAooooAKKKKACiiigAooooAKzPEWqvomg3WoRW7XDwLuEYIGecdz0rTqjrWm/2vo13Y eb5RnjKCTbu2nsccZ+maAKP/AAlVqLwQNa3axiZLaS4Kr5cUz4xGxDZzllGQCMnGapjx5ZuYxFpu qSGZZHh2wL+9EZw+3Lfw++M9s1L/AMI1dNcusl9AbCW7jvZYRbkMZVKsQG34Cl0DYIJ6jNS2fhj7 J/Z/+l7vsdvcQf6vG/zWU568Y29O+e1AFbUvEt7bwpqNrBbNpjrCYfMYiW7MmMCMDoQCOCDk56Dm tW71n7KGC6ffTyecYVSOMZfC7iwLEDb2ySOeKxrTwnqNhc2ksGp2Mv2S1itoftNg8hiCoFYoRKoU sRk8Z6DJAq7rXh641mSIzXVrJHFKzrBcWhkiKlQAGXeNzAgkHpz070AZ1742aNlmsbNry1lhspI1 UBX/AH8zRnOSBwAAB/ePPHI04/E9iLz7MkFwkPmvbpceWBC8qAlkBznI2sM4xkEZzWbB4Hlt9PWB NRQyRxW0cTm34BgnaZSVDc5yAQCOhI64Bb+Crey1cz79OEb3Es6MbFPtBZ9x2mUk8AsSMAHAAzgc gFiPxzaT29vNb6bqkv2mBriJFgXc8S7cvyw4+cYz17Z4zbm8VWkQt5BBdSWs6RP9qWMeUglICZJI POR0BxnnFFj4c+xf2f8A6Tv+x6abD/V4352fP14/1fT361iz/D55LeCIX1s5ggt4o5ZrPe8RiCj5 Dv8AkViuSBzyeemADQtfGHmLKsum3f2j7ZLbQ28QRnlCdW+9gADrkjqOua3NPv4NTsIru2LGKUZG 4YI7EEdiCCCPaubvvBH2ubzjNYzul1NPFHd2fmxgS43qy7hk5AIIxjpzXQ6Tpy6VpcFmhjIiXBMc SxKSTk4VeAMk8fzoAuUUUUAFFFFABRRRQAUUUUAFYejH7DrGp6W/GZTewf7SSHL/AJSb8+zL61uV k67YzypDf6eoOoWJLxKTgSofvxE/7QAx6MFPagDWoqtp9/BqljFd2rFopBkZGCp6FSOxByCOxFWa ACiiuA1bXJIvFoEV40Qj1CG2kjkvSp2MqhsQAY2ndnzGOc9O1AHeo6yLuRgw9Qc1V1exGqaNe2JI AuYHhye25SP615/pc1pa2ttaX+sXFjYqt428XrIxuFmI2ls5yFwQnfcSQae82sXdhNdXWp31texD TUKRSbVR5diykp0JO48HgHpQB6HbmVLOI3RQSrGPNIPy7sc8+maDeWwtBdG4i+zMocTbxsKnod3T ByK5nT5RBHf2txqV0PsmpPFamWcs8v8Ao4fy2Y8sPmc4P90elcre6ibrQP8AiY6tcRXYtLE2tsJs C4VkQu5T+PLFwTzt254oA9WqG7uEtLOa4kYIkUbOzHoABkmpqRlDqVYAqRggjgigDze71fV7qwvb Se8vIj5NpcpLJHCknzTbTtVM4Q8YDfNwc1tR6rqn2tLo3u6P+1Tp5sjGmCgJXfnG7fgeZ1xjjHet 2Pw5o0MbxxaVYojoY2VbdAGU4yDxyOBx7CpU0bTYr/7elhapdgY88RKHxjH3sZ6cfSgDiLXVPEdz YWcza0FNzpEmoHbax/KybMKOOh385544xmty/vp3t9JvHeOUXNxasLfylJiJViSCecnjHpj3q/oh tdTsjcR6fbRWeGgtMIPnt+BnGOEYjIXoQFP00BptkHDiztw42YYRLkbM7O3bJx6ZNAHH6HdXt94g 8P3t9fpcG902e4EKxqvkEmE7QRyQM4+bnKn6Duao2ui6ZY3L3Npp9pBO5JaSOFVY55PIGeTV6gAo oooAKxfC37ywu7gdJ7+5dfcCVlB/EKD+NWtd1FtL0ee4iXfcYEcCf35WO1F/FiKk0nT10rSLSxRi wt4ljLHqxA5J+p5/GgC5RRRQAUUUUAFFFFABXPT+Kls9X1C0uLKfy7UQCJk2kzvISAqjPUn1wODn AFdDXP6l4amvNRuLy3vI4ZJPIkj3wl/LkiYkE/MMqQxBHB560ADeMbUeXGLHUGvHleE2ixqZUdVD kH5tv3WBBzgg9ajtfGCatbN/ZFjcyXElv9otBcKI0nXcFJBzkAFhnIB9M1NZeG5IdUj1G5u0kuvO kmm2RbVctGsYAyxIAVF9c89KqHwfcR6baW9nqvkTW2nNYLN5BOQWjJbAYEcRkcHPzZzxQBb0vXbm ae8truFJ5LWeOBpbIFkLOBnIJyNufm5PBH0qLUfFqW1rqAitLiKeG1uJ7ZriMCOcxDnGG3YzjqBk cirel6XqGnWKWoudOSON02La2LRKEByy4Mrcn17dcGsL/hX0haQm+tg8kFxbvMLP97KJVI3SPvyz A4x0GM8DIwAaEHjD97fx3On3IeC7S0t0iCs1yzRLJhRu44JPOBtwc5yBLH4tsPNtbeC1uzLP5pMS QjMPluFk384GC3Xv2zkZpX/g5L+5uf8ASbSVvtUV4kNxa+aisIRCQ67vmVlUEdCDzk1c0zwqunSQ yCaBSltPCyQWqwpmV1bKqp4A2Ywck9zQAtj4xs7+IyLaX8am0+2Q+ZDzPHxygBJJyQMHHUdjmo5/ F+2S2ih02785r1LSeGTYHh3JvB4Yg5GOhPfvTbjwe0un2ltHqBja2037AHEZ+fmI7jhuh8rBXPRj yKhs/BcllK0kN1Zw5u4btY4LLy40KKUKhQ/Qg9c5zk89KANOw8T2mo3scEUNyiTb/s88iAR3Gz72 w5z78gZAyM1s1y2geCotC1CKWP7AYrcOIWjsVSdg39+XJJwDjgLnvXU0AFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFVr63NxbEJxIp3IfQirNFJq6sBBaXAurdZBwejD0PcVPWfM DYXRuFH7iU/vQP4T/eq+rBlBUgg8gilF9GAtFFFUAUUUUAFFFFABRRRQAUUUUAFFFcBrFzqMC65e RX9wETUorTDXBjit4CsJdsgHbySC+DtBJGOTQB1KaZPY6211YMgtbo5u4GJGHxxInH3jgBh34PUc 61ebQamxnsYdS13yNMe5uEWWDUJGUqscZCm4ZULYcthh/u5JzT4L7WLi1ubuG7vXms9G8+2hJ4nf fOscjrj5iVVTjuSPQUAejUm0ZzgZrza31K6Om3vla5a/ZttsTIdSmnVXL/MGn8seVvXjjO3g4Ga7 DwldG70GNy8z7ZJE3SzCbOHI4k/jXsGPJA55oA2SqnqAec8jvS0UUAZ41CRfET6fIqCJ7UTwsM7i QxWQH2GY/wAzV/AyDgZHesXX/wDRb/SNSHAhufs8p/6ZzDZ/6M8o/hW3QAUUUUAFYniSR7qO30aB isuosUkZTgxwD/Wt7cEKD2LitusPRv8AiY6vqOrNzHu+xW3+5GTvb8ZNw9wi0AbUcaRRrHGoREAV VAwAB0FOoooAKpavqsGi6bJfXQkMUbIpEa7myzBRgd+WFXao6vp39q2H2bzfK/fRS7tu77kivjGR 124/GgCgfFtqtwI5LS9RVaNJ5GjGy2eTG1H56/MucZA3DJFMh8ZWUxLfZb2OAmZUneMBJHi3F1Xn OcIx5ABweeKrXfgqK41+fUF+wFLiaOeUz2KyzKVCjCSMcKCFHVTjkjk8Z+i6Dcatpqx3GoxG2tbm 8McUcOWSR2lT5n3YbaJGOAAckZ6UAaj+LrC4t7eb+zb6fKG7Rfs6l44hwJcE8A5OMfMecCrsPia0 udSFraw3M6ZRWuIkDRoXQOobncMqQc4xz1rM1TwQl9LaSo9i8sNmtmxvLEXA2ryHQFhtbk9cg556 VM3hJjrNtdrcWyx2xjMbJahJ1VFA8vepA2HGcFTjJA7YAOlooooAKKKKACiiigAooooAKKKKACob q4S0tnmkyQo4A6sewHuTxUrMEUsxAUDJJPAFZ9vnUp1u3B+zIcwKf4z/AHz/AE/PuMJsTJ7C3eGF nnwbiZvMlI6A+g9gAB+FWqKKYwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigBGUMpVgCDwQaz8SaYxwGktD2HJj/wDrVo0UmrgMjkSZA8bBlPQin1SksWicy2Ti Jz1Q/cb8O1CaiI2CXkZgf1PKn6GlzW3Au0UisGUFSCD0IpaoAooooAKKKKACiiigApCMjBpaKAKs un2815bXLqfMtldYwOgDAA8fgKtUUUAZWq3txpTLcG2WfTcEXAjUmWL/AG8fxL6gDI689BowTRXE Ec1u6SROoZHQ5VgehBHapK5+a0n8OTvd6ZE82nOxe5skGWjJ5MkQ/Up36jnIYA6CiobS7gv7SO5t JUmglXcjochhU1AFHWtP/tXRbyyDbXmiZUf+4+Plb8Dg/hS6NqH9q6NaXu3a08Ssyf3Gx8y/gcj8 Ku1iaF/oep6tpZ4WOb7XCP8ApnNlj/5EEv6UAbdFFFAGdr1++maJdXMIDThdkCn+KViFQfixUVNp dgmlaVa2MRLLbxLHuPVsDkn3J5/Gs/WP9M17R9P6qrveyj1WMAKD/wADdD/wGtugAooooAKQkAZP AqG8vbfT7SS5vJkhgjGWdzgD/PpWL9muvE53X8clppHVbRvlkufeX+6n+x1P8X92gAku5/EztBpk rwaWCVmvkOGn9UhPp6yfgvPI27S0gsbWO2tYkigiXaiIMBRUiIsaKiKFVRgKBgAelOoAKKKKACii igAooooAKKKKACiimvIkSF5GVFUZLMcAUAOqOe4itojLM4RB3NVP7QkueNPhMgP/AC2k+WMfTu34 ce9PgsAsonuZDcTjozDCp/ur0H8/elfsK/YjEUmplWuY2itQcrC3WT0LjsP9n8/StCiihIYUUUUw CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAprIrqV dQynqCM06igCk2mqjFrWV4G9FOVP4UnmX8H34knX1Q7T+VXqKnlXQCkuqQZ2y74W9JFIq1HLHKMx urj/AGTmlZVcYYAj0IqtJplq5z5QRvVDt/lR7yAt0VS+wSx/6i8mX2fDijGox9GglHuCpo5n1QF2 iqX2y5T/AFtlJ9Y2DUDVbcHEnmRH0dCKOZAXaKgjvLeX7k0ZPpu5qaqTuAtFFFABRRRQBhXen3Oj 3cmo6NGZI5G33dgDgSnu8fZZPUdG74PNalhqFtqdml1aSCSJ884wQRwQQeQQeCDyDVmsTUNMuLK8 fVNFUG4bBubUnal0B39FkA6N36HjBABt1iar/oPiDStQHCSlrGY+z/MhP0dQo/66VoabqVvqtmtz bM20kqyuu142HBVgeQQeoqDxDZm/0C8gV1jk8vfE7HASRfmRvwYA/hQBpUVj+H/E+meI7dWsLqKW YQxyzRI2TFuHQ++QRjtirGq67pmhpE2qXsNqspIjMrbdxAyQKAKmmf6X4m1e86rB5VlH/wABXzHI /GQA/wC5W3WP4UjZfDttPIMS3e67k5zhpWLkfhux+FbFABWfqmswaZ5cex7i7myILWHmSU9/YAd2 OAPWqt7rE092+naIiT3icTTPkw2v+9j7zeiDn1IHNWdL0aHTPMl3vcXk2PPupuZJPQegUdlGAKAK 1no89zdx6jrjJNdId0FuhzDa/wC7n7z/AO2fwAHXaoooAKKKKACiiq899a2xxPcwxn0dwDQBYoqj /a0Df6lJ5v8ArnCxH54x+tH2u8k/1WnsvvPKq/8AoO40roVy9RVHy9Sk+9PbQj0SMufzJH8qP7NM n/HxeXUvsH8sf+OAUXC5amuIbZN88scS+rsAP1qr/asUn/HrFPcnsY4yF/76OF/WpIdNs7d98VtE H/vlct+Z5q1RqGpR/wCJjP8A88LVfxkf+gH60qaXBvEk++5kHIaY7sH2HQfgBV2iiwWCiiimMKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACkIBGDS0UAQSWVtL9+CM++3BqH+yoF/wBS0sJ/2HIq7RS5U+gFH7Ld x/6q83D0kQH9aPOv4v8AWW8co9Y3x+hq6zBRk1hX+tzyX503SIFub1VDSF22xW6noXYA8nso5PsO aXL2YGiNVhBxMskJ/wBtasJcxSDKSKw9jmsVfDM10N2r6ve3DHrHbubaIfQId/5sasjwzpn2Y25i maM9d1zKzf8AfRbP60agafmp60eanrWN/wAIbo3/AD7z/wDgXN/8VR/whujf8+8//gXN/wDFVQCa pZTW102r6MAbwKBPbZCreIOxPQOP4W/A8dG38Gl+OfC89pKz/Z7gbGBG2SGRT3HZlYdD6elP/wCE N0b/AJ95/wDwLm/+KpieCNCjkd0tJVeQguwupQWxxz83NAHF/CDw9d+F9Y8SWWoIVeNoBHJj5ZF/ efMp7g8fTpU/xj0a78R22iWOmxGWd7ph7KCvLMewHrXYf8Ibo3/PvP8A+Bc3/wAVR/whujf8+8// AIFzf/FUAM8I+HbPwh4fi063lMhX55pWP33PU47Djp/XJqN9Qn8SOYdMna20sHEt8nDz+qw+g9ZP ++fUSyeCdDmiaOS1mZHBVlN1MQQeoPzUq+DNFVQq20wAGABdzcf+PUAaVlbWmm2iWtnEkMKfdVf1 J9SepJ5NWPNT1rG/4Q3Rv+fef/wLm/8AiqP+EN0b/n3n/wDAub/4qgDXe5iiQvJIqKOpY4FVv7Xt 3/49lluT/wBMUJX/AL6OF/WqDeC9FbGbecEdCt5MCPxD5pG8OXNp82k6veQsOkV0xuYj9dx3/k1L UWpoedqEv+rtYYR6zSZP5KMfrR9kvJP9dfsvtBEqj/x7capadrcpvjp2qwC1vwu9VDbo51HVo2wM 44yCARkZGCCdoHIosFil/ZNs3+u82f8A66ysw/LOP0qxBZ29sMQQRRf7iBf5VNRRZBZBRRRTGFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGfq14LS1kkOcIpY49hVTwh ai38N2kzYNxeILu4fu8jgMee4GQo9lA7VJraF7dhjIIrH8E65EkCeHrttl5Zpsg3dJ4V4Ug/3lGA R14z0NAHX1i3PiNbc6hm3LfY723tD8/3zL5XzdOMeb074962qwr3wpb31/LcNe3kcc08NxLbxsgj eSIrtY5Ut/AoIzjigCnH4uvJzCLfRi32m8ltLcvchQ5j8zcx+U7V/d+556dM2G8USr4cOr/2c3lx xTNOnnDMckbbSnTnJDc/7PvVy38P2tt9i2STH7HcTXEeSOWl37geOn7xsfQdajfwzbPpcunG4uvs sy3CyIGX5jM5cnO3OVJO3685oAS78Rra6z/Z5tyx8yCPfvx/rfM5xjt5f61Qu/F6W147PFMI7dbs GNGU+a0TRAdRnJL4HIHPOeMTnwfE5nml1PUJLyV4ZPtLGPcjRZ2kAJt/iIIxg/XmgeCbAwuk1xeT GRbgO7uu4mYoXbhRggoCMdPywAM03WdXuNZ1KC508RvbxWpS2Eyso3vIHcPgZwoHB7oQOuTNDf6q 3ijU7GT7KY47OOa1Rc9WeQfOevO0dOlS2Xhw2k11cNql/NdXQhEk7mMHEbEgABAACGIPHQ9jzVq4 0eKe8u7oTTxTXNoLQtGwGxQXIZeOGy5556DigDAs9Q1qaW9tLfUrW7aGFPNvGhCxW82/DqpHDbU3 HB5BABPPFc65rE1kPsMl1e25vvKivba0UvLCISxYA4THmfKG4BHT30/+EOB0ZtKfWtSazKIix7LZ QgVgwxiIZzjBByCCcjmrZ0G4aBFbXNTaaJ98c2IFK/KVK7VjCsvPQg8gYxQBY0G+TUdGguEuJLjd uVnkjEb7gxDBlHQgggj2rRrLtdDWyshbW17eRr5UiFgyFi7tuMpyv38kn05PFXobdopZHa4mkDhc I+MJgY4wB16nOfwoAmooooAwvGUI/wCEbur1cC405TeQv3DRjcRn0ZQVPsxrTsp/OhVh3Ga5nxlr Ud0T4csz5k9yALtl+7BDkZVv9pxwB6En0z0GlqRAufSgDQooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigCvdQCWMjFcN4h8NLctu2cqdysOCpHQgjkH3FegV DNbJKORQB5rb6/4p0ceWt1FexL0F5FuYD03qQfxOatD4ha6ow2k2RPqJnH9K6+fRYpD90VVbw7ET 9wUAc1/wsTW/+gRZ/wDf9/8A4mj/AIWJrf8A0CLP/v8Av/8AE10f/COR/wBwUf8ACOR/3BQBzn/C xNb/AOgRZ/8Af9//AImj/hYmt/8AQIs/+/7/APxNdH/wjkf9wUf8I5H/AHBQBzn/AAsTW/8AoEWf /f8Af/4mj/hYmt/9Aiz/AO/7/wDxNdH/AMI5H/cFH/COR/3BQBzn/CxNb/6BFn/3/f8A+Jo/4WJr f/QIs/8Av+//AMTXR/8ACOR/3BR/wjkf9wUAc5/wsTW/+gRZ/wDf9/8A4mj/AIWJrf8A0CLP/v8A v/8AE10f/COR/wBwUf8ACOR/3BQBzp+IOusMJpNkp9TM5/oKrTa14o1oeXJeJZxNwVsoyjEf77En 8RiuuXw7ED9wVcg0eOP+EUAc34e8OJZqNse3J3E9yT1JPc+9dpBEI0AoigWMcCpaACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigApKWigBKKWigBK KWigBKKWigBKKWigBKKWigBKWiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooA//2Q== --Apple-Mail-74--1033306506 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit and let us look at the application of this definition to the example of our graph above. Here you see that the does not have 1 representation, but two representations: the yellow and the green "..." representations. One of these representations (the yellow, older one) had a link to , while the other (the greener, newer one) had a link to . So according to your definition the green tom2:alternate arrow (the one that arises from the information in the green entry) says is that these two yellow and green entry representations are alternates of the green "..." and "..." representations. But that is not quite what we want to say, since that would make the older yellow "..." representation an alternative of the newer green html and xhtml representations. These might have changed only a little during the displacement, but they may also have changed a lot more. This just does not seem quite right. Now I can hear you think (amazing powers that I have :-) that what you really mean is that the green entry representation alone (not the older yellow one) is an alternate version of the representation of the resource. But if you mean to say that, then why bring the id of the entry into the picture at all? Let us just cut it out, since the link construct can indexically refer to the representation in which it is located. [[ The value "alternate" signifies that the IRI in the value of the href attribute identifies a resource whose representations are an alternate version of the containing element. ]] Now I think we have another way of saying what I meant by the A:alternate relation. Which of the phrasings is better, the one above or [[ The value "alternate" signifies that the containing element is an alternative representation of the resource identified by the IRI in the value of the href attribute. ]] is now a matter of which one is clearer. But I think we are describing the same relation. Henry Story --Apple-Mail-74--1033306506-- From owner-atom-syntax@mail.imc.org Sun Apr 3 18:09:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01040 for ; Sun, 3 Apr 2005 18:09:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33M2hc6064820; Sun, 3 Apr 2005 15:02:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33M2hd2064819; Sun, 3 Apr 2005 15:02:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33M2g5G064812 for ; Sun, 3 Apr 2005 15:02:42 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j33M2gX8017757 for ; Sun, 3 Apr 2005 16:02:42 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEE0061758IOT@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 03 Apr 2005 16:02:42 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEE00H6S58HJS@mail.sun.net> for atom-syntax@imc.org; Sun, 03 Apr 2005 16:02:42 -0600 (MDT) Date: Sun, 03 Apr 2005 15:03:08 -0700 From: Tim Bray Subject: Re: Why is alternate link a MUST? In-reply-to: To: Graham Cc: "Atom-Syntax Syntax'" , Joe Gregorio Message-id: <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 3, 2005, at 12:45 PM, Graham wrote: > So do you have an argument here as to why it should be required? All > I'm seeing is that it's easy to workaround when the publisher omits > it. Agreed. Joe, that wasn't very convincing. I repeat, we've seen several very believable use-cases for why someone might want this, and no good arguments (that I can remember) that it would break anything. Sam has pointed out that no previous version of RSS has done this, which is a reasonable argument; except for we have use-cases, and nobody's shown that the cost is non-zero. -Tim From owner-atom-syntax@mail.imc.org Sun Apr 3 18:37:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03466 for ; Sun, 3 Apr 2005 18:37:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33MUitU066452; Sun, 3 Apr 2005 15:30:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33MUiPM066451; Sun, 3 Apr 2005 15:30:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33MUhNv066445 for ; Sun, 3 Apr 2005 15:30:43 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.8]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DIDc6-0003s0-PD; Sun, 03 Apr 2005 22:30:38 +0000 Message-ID: <42506E8C.8030409@franklinmint.fm> Date: Sun, 03 Apr 2005 18:30:36 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Graham , "Atom-Syntax Syntax'" , Joe Gregorio Subject: Re: Why is alternate link a MUST? References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> In-Reply-To: <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > Agreed. Joe, that wasn't very convincing. I repeat, we've seen several > very believable use-cases for why someone might want this, and no good > arguments (that I can remember) that it would break anything. Sam has > pointed out that no previous version of RSS has done this, which is a > reasonable argument; except for we have use-cases, and nobody's shown > that the cost is non-zero. -Tim I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss and removed the element. This absence caused Bloglines to behave oddly. Robert Sayre From owner-atom-syntax@mail.imc.org Sun Apr 3 18:53:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04798 for ; Sun, 3 Apr 2005 18:53:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33MlaB4068131; Sun, 3 Apr 2005 15:47:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33MlaaQ068130; Sun, 3 Apr 2005 15:47:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from faceman.dreamhost.com (postfix@faceman.dreamhost.com [205.196.210.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Mla3C068124 for ; Sun, 3 Apr 2005 15:47:36 -0700 (PDT) (envelope-from arve@virtuelvis.com) Received: from wintermute (ti132110a080-0138.bb.online.no [85.165.128.138]) by faceman.dreamhost.com (Postfix) with ESMTP id 6DD38111D83; Sun, 3 Apr 2005 15:47:34 -0700 (PDT) To: mint@franklinmint.fm Cc: atom-syntax@imc.org Subject: Re: Why is alternate link a MUST? References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> <42506E8C.8030409@franklinmint.fm> Message-ID: Date: Mon, 04 Apr 2005 00:46:12 +0200 From: "Arve Bersvendsen" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <42506E8C.8030409@franklinmint.fm> User-Agent: Opera M2(BETA3)/8.0 (Win32, build 7537) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 04 Apr 2005 00:30:36 +0200, Robert Sayre wrote: > I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss and > removed the element. This absence caused Bloglines to behave > oddly. In what sense? Please be aware that the absence of is not something I think you'd usually see on the public web, anyway. -- Arve From owner-atom-syntax@mail.imc.org Sun Apr 3 18:56:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04946 for ; Sun, 3 Apr 2005 18:56:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33MpDvM068645; Sun, 3 Apr 2005 15:51:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33MpDNR068644; Sun, 3 Apr 2005 15:51:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33MpCPi068633 for ; Sun, 3 Apr 2005 15:51:13 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.2.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j33MoIYG023829; Sun, 3 Apr 2005 23:50:24 +0100 (BST) In-Reply-To: <42506E8C.8030409@franklinmint.fm> References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> <42506E8C.8030409@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6a6b373d805849d0384d5d818085889b@mac.com> Content-Transfer-Encoding: 7bit Cc: "Atom-Syntax Syntax'" , Joe Gregorio , Tim Bray From: Graham Subject: Re: Why is alternate link a MUST? Date: Sun, 3 Apr 2005 23:50:25 +0100 To: mint@franklinmint.fm X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3 Apr 2005, at 11:30 pm, Robert Sayre wrote: >> arguments (that I can remember) that it would break anything. Sam >> has pointed out that no previous version of RSS has done this, which >> is a reasonable argument; except for we have use-cases, and nobody's >> shown that the cost is non-zero. -Tim > > I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss > and removed the element. This absence caused Bloglines to > behave oddly. I copied Tim's feed and renamed the description elements to "summary" and the items to "entry". This caused Bloglines to behave oddly*. (* actually it didn't, but that's not the point) Graham From owner-atom-syntax@mail.imc.org Sun Apr 3 18:58:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05061 for ; Sun, 3 Apr 2005 18:58:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33MrZM7068812; Sun, 3 Apr 2005 15:53:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33MrZMV068811; Sun, 3 Apr 2005 15:53:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33MrYRK068805 for ; Sun, 3 Apr 2005 15:53:35 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.8]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DIDyF-0004AB-2n; Sun, 03 Apr 2005 22:53:31 +0000 Message-ID: <425073E8.8070606@franklinmint.fm> Date: Sun, 03 Apr 2005 18:53:28 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arve Bersvendsen CC: atom-syntax@imc.org Subject: Re: Why is alternate link a MUST? References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> <42506E8C.8030409@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Arve Bersvendsen wrote: > > On Mon, 04 Apr 2005 00:30:36 +0200, Robert Sayre > wrote: > >> I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss >> and removed the element. This absence caused Bloglines to >> behave oddly. > > > In what sense? Sorry, I was a little unclear. Bloglines made "Ongoing" a hyperlink, but it linked to the page I was already looking at without the navigation frame. > Please be aware that the absence of is not something I think > you'd usually see on the public web, anyway. I see Graham has written about "the point", which is that existing UIs often assume the availability of a link from the feed. This is a SHOULD, with stern warnings, minimum. Robert Sayre From owner-atom-syntax@mail.imc.org Sun Apr 3 19:00:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05181 for ; Sun, 3 Apr 2005 19:00:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Mtfrc069541; Sun, 3 Apr 2005 15:55:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33MtfOw069540; Sun, 3 Apr 2005 15:55:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33MtdYM069533 for ; Sun, 3 Apr 2005 15:55:41 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <42506E8C.8030409@franklinmint.fm> References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> <42506E8C.8030409@franklinmint.fm> Date: Sun, 3 Apr 2005 15:55:36 -0700 To: From: Paul Hoffman Subject: Re: Why is alternate link a MUST? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We are creating a new protocol. We don't expect any current reader to behave well with it before it is done. Quoting from RFC 2119, which is what we are using to define MUST and SHOULD: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Why is the alternate link "actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions)"? It seems like a perfect candidate for MAY, like most of the rest of the format. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sun Apr 3 19:13:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05792 for ; Sun, 3 Apr 2005 19:13:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33N4onr070164; Sun, 3 Apr 2005 16:04:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33N4oia070162; Sun, 3 Apr 2005 16:04:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j33N4nLB070144 for ; Sun, 3 Apr 2005 16:04:50 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 39483 messnum 5758826 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 3 Apr 2005 23:04:43 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail12.svc.cra.dublin.eircom.net (qp 39483) with SMTP; 3 Apr 2005 23:04:43 -0000 Message-ID: <42507689.9070703@dehora.net> Date: Mon, 04 Apr 2005 00:04:41 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Graham , "Atom-Syntax Syntax'" , Joe Gregorio Subject: Re: Why is alternate link a MUST? References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> In-Reply-To: <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Apr 3, 2005, at 12:45 PM, Graham wrote: > >> So do you have an argument here as to why it should be required? All >> I'm seeing is that it's easy to workaround when the publisher omits it. > > > Agreed. Joe, that wasn't very convincing. I repeat, we've seen several > very believable use-cases for why someone might want this, and no good > arguments (that I can remember) that it would break anything. Sam has > pointed out that no previous version of RSS has done this, which is a > reasonable argument; except for we have use-cases, and nobody's shown > that the cost is non-zero. -Tim The top level feed stuff doesn't make a lot of sense to me. That @alternate is mandatory while @self and atom:id are not isn't very convincing either: atom:link[@rel='alternate'] : MUST atom:link[@rel='self'] : SHOULD atom:id : MAY You can't have a useful discussion about @alternate without talking about @self or atom:id. Thus: I'm -1 to downgrading @alternate unless @self is lifted to MUST or atom:id is lifted to MUST. If either are lifted to must I'm 0 on downgrading @alternate. At that stage @alternate doesn't matter a whole lot. cheers Bill From owner-atom-syntax@mail.imc.org Sun Apr 3 19:14:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05859 for ; Sun, 3 Apr 2005 19:14:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33N9NDp070514; Sun, 3 Apr 2005 16:09:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33N9N1P070513; Sun, 3 Apr 2005 16:09:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33N9IpK070492 for ; Sun, 3 Apr 2005 16:09:18 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j33N9HRr013195 for ; Sun, 3 Apr 2005 17:09:17 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEE006EX8BHOT@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 03 Apr 2005 17:09:17 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEE002UY8BGUG@mail.sun.net> for atom-syntax@imc.org; Sun, 03 Apr 2005 17:09:17 -0600 (MDT) Date: Sun, 03 Apr 2005 16:09:44 -0700 From: Tim Bray Subject: Re: Why is alternate link a MUST? In-reply-to: <42506E8C.8030409@franklinmint.fm> To: mint@franklinmint.fm Cc: Graham , "Atom-Syntax Syntax'" , Joe Gregorio Message-id: <478555853232035fe2c02cc5cf10859d@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> <42506E8C.8030409@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 3, 2005, at 3:30 PM, Robert Sayre wrote: >> Sam has pointed out that no previous version of RSS has done this, >> which is a reasonable argument; except for we have use-cases, and >> nobody's shown that the cost is non-zero. -Tim > > I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss > and removed the element. This absence caused Bloglines to > behave oddly. Well, yeah, but when they do the half-hour's coding it's going to cost them to start supporting Real IETF Atom 1.00 (tm), they can do an extra 3 minutes and if there's no , they don't make the subscription clickable. Works fine in NetNewsWire btw. -Tim From owner-atom-syntax@mail.imc.org Sun Apr 3 19:20:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06258 for ; Sun, 3 Apr 2005 19:20:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33NBxHE070751; Sun, 3 Apr 2005 16:11:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33NBxQm070750; Sun, 3 Apr 2005 16:11:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33NBw5p070744 for ; Sun, 3 Apr 2005 16:11:58 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id f1so1604453rne for ; Sun, 03 Apr 2005 16:11:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=RSe9MrPsmUPd9GLrf8ZQrwamiygD9tlTqLdI9BG7FcpwWYSukghuBEjita8CdXQYHmBU82CeG+MHj9cC0ukBqHfuU/Vd55XtCeaygiYQcmFGw6LCGN6fjdYWIT4RhpcpmjWel9kyJgqtXioAwQ1SkZNBNC6IMpyQ3hH6/S0ah1Y= Received: by 10.38.72.79 with SMTP id u79mr4730141rna; Sun, 03 Apr 2005 16:11:58 -0700 (PDT) Received: by 10.38.151.18 with HTTP; Sun, 3 Apr 2005 16:11:58 -0700 (PDT) Message-ID: <3f1451f5050403161146417b8f@mail.gmail.com> Date: Sun, 3 Apr 2005 19:11:58 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: Why is alternate link a MUST? Cc: Tim Bray , Graham , "Atom-Syntax Syntax'" In-Reply-To: <42507689.9070703@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> <42507689.9070703@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j33NBw5p070745 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Apr 3, 2005 7:04 PM, Bill de hÓra wrote: > Tim Bray wrote: > > > > On Apr 3, 2005, at 12:45 PM, Graham wrote: > > > >> So do you have an argument here as to why it should be required? All > >> I'm seeing is that it's easy to workaround when the publisher omits it. > > > > > > Agreed. Joe, that wasn't very convincing. I repeat, we've seen several > > very believable use-cases for why someone might want this, and no good > > arguments (that I can remember) that it would break anything. Sam has > > pointed out that no previous version of RSS has done this, which is a > > reasonable argument; except for we have use-cases, and nobody's shown > > that the cost is non-zero. -Tim > > The top level feed stuff doesn't make a lot of sense to me. That > @alternate is mandatory while @self and atom:id are not isn't very > convincing either: > > atom:link[@rel='alternate'] : MUST > atom:link[@rel='self'] : SHOULD > atom:id : MAY > > You can't have a useful discussion about @alternate without talking > about @self or atom:id. > > Thus: I'm -1 to downgrading @alternate unless @self is lifted to MUST or > atom:id is lifted to MUST. If either are lifted to must I'm 0 on > downgrading @alternate. At that stage @alternate doesn't matter a whole lot. For me David Nesting's example of an Atom document as an email attachment was the most convincing that @alternate doesn't need to be a MUST. I agree here with Bill and personally prefer to see atom:id lifted to a MUST. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sun Apr 3 19:20:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06279 for ; Sun, 3 Apr 2005 19:20:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33NDVej071133; Sun, 3 Apr 2005 16:13:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33NDVRG071131; Sun, 3 Apr 2005 16:13:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33NDTda071099; Sun, 3 Apr 2005 16:13:29 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j33NDSX8012052; Sun, 3 Apr 2005 17:13:28 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEE005HM8IGN9@edgemail1.Central.Sun.COM>; Sun, 03 Apr 2005 17:13:28 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEE002VM8IFUG@mail.sun.net>; Sun, 03 Apr 2005 17:13:28 -0600 (MDT) Date: Sun, 03 Apr 2005 16:13:55 -0700 From: Tim Bray Subject: Re: Why is alternate link a MUST? In-reply-to: To: Paul Hoffman Cc: atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> <42506E8C.8030409@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 3, 2005, at 3:55 PM, Paul Hoffman wrote: > Why is the alternate link "actually required for interoperation or to > limit behavior which has > potential for causing harm (e.g., limiting retransmisssions)"? > > It seems like a perfect candidate for MAY, like most of the rest of > the format. I think is a SHOULD, to address auto-subscriptions, one of the current #1 RSS pain points, perceived by users as a failure to interoperate. -Tim From owner-atom-syntax@mail.imc.org Sun Apr 3 19:22:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06320 for ; Sun, 3 Apr 2005 19:21:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33NC2g1070773; Sun, 3 Apr 2005 16:12:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33NC2Qk070772; Sun, 3 Apr 2005 16:12:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33NC1ei070765 for ; Sun, 3 Apr 2005 16:12:01 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j33NC1Rr014134 for ; Sun, 3 Apr 2005 17:12:01 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEE006H98G1OT@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 03 Apr 2005 17:12:01 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEE002VE8FUUG@mail.sun.net> for atom-syntax@imc.org; Sun, 03 Apr 2005 17:12:01 -0600 (MDT) Date: Sun, 03 Apr 2005 16:12:22 -0700 From: Tim Bray Subject: Re: Why is alternate link a MUST? In-reply-to: <42507689.9070703@dehora.net> To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Cc: Graham , "Atom-Syntax Syntax'" , Joe Gregorio Message-id: <640e482c290f20cc0d970e0528b44927@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> <42507689.9070703@dehora.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Just so everyone's clear: what we're arguing about is on , not on . -Tim From owner-atom-syntax@mail.imc.org Sun Apr 3 19:23:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06542 for ; Sun, 3 Apr 2005 19:23:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33NH4WL072211; Sun, 3 Apr 2005 16:17:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33NH4OF072210; Sun, 3 Apr 2005 16:17:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33NH3ku072197 for ; Sun, 3 Apr 2005 16:17:03 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.8]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DIEKv-0004Qe-TI; Sun, 03 Apr 2005 23:16:58 +0000 Message-ID: <42507967.2000105@franklinmint.fm> Date: Sun, 03 Apr 2005 19:16:55 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Graham , "Atom-Syntax Syntax'" , Joe Gregorio Subject: Re: Why is alternate link a MUST? References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> <42506E8C.8030409@franklinmint.fm> <478555853232035fe2c02cc5cf10859d@sun.com> In-Reply-To: <478555853232035fe2c02cc5cf10859d@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > Well, yeah, but when they do the half-hour's coding it's going to cost > them to start supporting Real IETF Atom 1.00 (tm), they can do an extra > 3 minutes and if there's no , they don't make the subscription > clickable. I doubt they've never encountered a feed without a link. Why do you think they didn't fix it? For example, they will accurately parse a feed that sends a unix timestamp instead of an RFC822 date. Robert Sayre From owner-atom-syntax@mail.imc.org Sun Apr 3 19:59:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08421 for ; Sun, 3 Apr 2005 19:59:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Nolmw082040; Sun, 3 Apr 2005 16:50:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33NolQv082039; Sun, 3 Apr 2005 16:50:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf06.cluster1.charter.net (mxsf06.cluster1.charter.net [209.225.28.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33Noklo082010 for ; Sun, 3 Apr 2005 16:50:46 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from mxip06.cluster1.charter.net (mxip06a.cluster1.charter.net [209.225.28.136]) by mxsf06.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j33NoeTT009324 for ; Sun, 3 Apr 2005 19:50:40 -0400 Received: from cpe-68-112-233-63.ma.charter.com (HELO localhost) (68.112.233.63) by mxip06.cluster1.charter.net with ESMTP; 03 Apr 2005 19:50:39 -0400 X-Ironport-AV: i="3.91,144,1110171600"; d="scan'208"; a="816894312:sNHT40963818" Received: from ndw by localhost with local (Exim 4.50) id 1DIErT-0001WW-Id for atom-syntax@imc.org; Sun, 03 Apr 2005 19:50:35 -0400 To: atom-syntax@imc.org Subject: Re: Why is alternate link a MUST? References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <6.0.0.20.2.20050403101341.02fb0b20@itmail.it.aoyama.ac.jp> From: Norman Walsh X-URL: http://nwalsh.com/ Date: Sun, 03 Apr 2005 19:50:35 -0400 In-Reply-To: (Arve Bersvendsen's message of "Sun, 03 Apr 2005 14:57:29 +0200") Message-ID: <87fyy7fmic.fsf@nwalsh.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / "Arve Bersvendsen" was heard to say: | n Sun, 03 Apr 2005 03:14:33 +0200, Martin Duerst | wrote: | |> Of course I'm also for making an alternate link for a feed a |> MAY rather than a MUST. | | +1 | | I don't see any advantage at all in forcing an alternative | representation to exist, and I have yet to see a real argument[1] why | such an alternative representation must exist . I have to vote +1 on this too. Twice now I've wanted to generate feeds (once for Subversion change logs and once for the 404s produced by my web server) where I thought the manditory alternate link was inpractical or impossible. For the Subversion case, I actually generated HTML pages so that I could point to them, but that's only because it felt geeky enough to be entertaining. For the 404 case, I use the 404 link as the alternate representation and that's just...pointless. Be seeing you, norm =2D-=20 Norman Walsh | Human felicity is produced not so much http://nwalsh.com/ | by great pieces of good fortune that | seldom happen, as by little advantages | that occur every day.--Benjamin Franklin --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCUIFLOyltUcwYWjsRAvDWAJoC8tN9bTY3ouZgY+kyL7duO4+6xQCdEJFx EQyo162Qw/V7KA53glfNFo8= =pa4t -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Sun Apr 3 20:00:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08487 for ; Sun, 3 Apr 2005 20:00:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33NpFQj082178; Sun, 3 Apr 2005 16:51:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j33NpFWU082176; Sun, 3 Apr 2005 16:51:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf18.cluster1.charter.net (mxsf18.cluster1.charter.net [209.225.28.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j33NpE8H082146 for ; Sun, 3 Apr 2005 16:51:15 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from mxip19.cluster1.charter.net (mxip19a.cluster1.charter.net [209.225.28.149]) by mxsf18.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j33Np8TJ019997 for ; Sun, 3 Apr 2005 19:51:08 -0400 Received: from cpe-68-112-233-63.ma.charter.com (HELO localhost) (68.112.233.63) by mxip19.cluster1.charter.net with ESMTP; 03 Apr 2005 19:51:08 -0400 X-Ironport-AV: i="3.91,144,1110171600"; d="scan'208"; a="950651189:sNHT20298768" Received: from ndw by localhost with local (Exim 4.50) id 1DIErv-0001Wj-Dy for atom-syntax@imc.org; Sun, 03 Apr 2005 19:51:03 -0400 To: atom-syntax@imc.org Subject: Re: Why is alternate link a MUST? References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <20050402225748.GM30546@home.fastolfe.net> <6.0.0.20.2.20050403101341.02fb0b20@itmail.it.aoyama.ac.jp> <42505EA6.3030906@franklinmint.fm> From: Norman Walsh X-URL: http://nwalsh.com/ Date: Sun, 03 Apr 2005 19:51:03 -0400 In-Reply-To: <42505EA6.3030906@franklinmint.fm> (Robert Sayre's message of "Sun, 03 Apr 2005 17:22:46 -0400") Message-ID: <87br8vfmhk.fsf@nwalsh.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Robert Sayre was heard to say: | Martin Duerst wrote: |> Of course I'm also for making an alternate link for a feed a |> MAY rather than a MUST. | | I'm in favor of keeping it a MUST, but I could live with it becoming a | SHOULD. As Sam says, all versions of RSS have made it a requirement. | Feeds without a link will probably break some clients, so you better | know what you're doing. OTOH, there have been some persuasive | arguments for making it optional. | | If we change it, SHOULD seems like the right way to go: "the | distinction between 'SHOULD' and 'MUST' in RFC2119 doesn't apply to | stupid implementors."[0] :) SHOULD works for me. Be seeing you, norm =2D-=20 Norman Walsh | In a universe of electrons and selfish http://nwalsh.com/ | genes, blind physical forces and | genetic replication, some people are | going to get hurt, other people are | going to get lucky, and you won't find | any rhyme or reason in it, nor any | justice.--Richard Dawkins --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCUIFnOyltUcwYWjsRAldNAJ9TQsu98HvkunEYncUepk/2tyiOWACfZTTo 14H5FWr5jVBGWM+QbOBk+QY= =tLez -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Sun Apr 3 23:11:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20123 for ; Sun, 3 Apr 2005 23:11:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3430X7O032148; Sun, 3 Apr 2005 20:00:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3430XqM032147; Sun, 3 Apr 2005 20:00:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from afc.gov.au ([210.193.203.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3430Utc032138 for ; Sun, 3 Apr 2005 20:00:32 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.25.1] (HELO [192.168.45.41]) by afc.gov.au (CommuniGate Pro SMTP 4.2.9) with ESMTP id 2239431 for atom-syntax@imc.org; Mon, 04 Apr 2005 13:00:29 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 04 Apr 2005 12:59:57 +1000 Subject: Re: Why is alternate link a MUST? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <42507689.9070703@dehora.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3430Xtc032142 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/4/05 9:04 AM, "Bill de hÓra" wrote: > Thus: I'm -1 to downgrading @alternate unless @self is lifted to MUST or > atom:id is lifted to MUST. If either are lifted to must I'm 0 on > downgrading @alternate. At that stage @alternate doesn't matter a whole lot. -1: the reasons against @self MUST are similar to the reasons against @alternate MUST. I'll be happy with: self: MAY alternate: MAY id: SHOULD or possibly even: self: SHOULD alternate: SHOULD id: MUST e. From owner-atom-syntax@mail.imc.org Sun Apr 3 23:39:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21887 for ; Sun, 3 Apr 2005 23:39:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j343WTnK034038; Sun, 3 Apr 2005 20:32:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j343WSqG034037; Sun, 3 Apr 2005 20:32:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j343WRGZ034030 for ; Sun, 3 Apr 2005 20:32:28 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 3 Apr 2005 20:32:25 -0700 To: Atom Syntax From: Paul Hoffman Subject: Re: Why is alternate link a MUST? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Not to pick on Eric; others have said things along the lines of: At 12:59 PM +1000 4/4/05, Eric Scheid wrote: >I'll be happy with: > > self: MAY > alternate: MAY > id: SHOULD > >or possibly even: > > self: SHOULD > alternate: SHOULD > id: MUST This isn't a negotiating game. We have to have technical reasons for our assigning requirements levels. To repeat the relevant section from RFC 2119 (which is only two pages long, really): 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. What is the technical reasons for the SHOULDs and MUSTs? Where is the interoperability issues within the protocol (not with readers that don't know what the protocol looks like)? What are the potentials for causing harm? I'm not saying there are none; I'm saying let's choose our levels based on what we are supposed to be choosing from. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Apr 4 00:09:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24283 for ; Mon, 4 Apr 2005 00:09:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34406Wa040149; Sun, 3 Apr 2005 21:00:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34406sv040148; Sun, 3 Apr 2005 21:00:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j344040k040131; Sun, 3 Apr 2005 21:00:06 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12ld22h.cable.mindspring.com ([69.86.136.81] helo=[192.168.1.102]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DIIkg-00085n-L0; Mon, 04 Apr 2005 03:59:50 +0000 Message-ID: <4250BBB9.9030009@franklinmint.fm> Date: Sun, 03 Apr 2005 23:59:53 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Atom Syntax Subject: Re: Why is alternate link a MUST? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > > What is the technical reasons for the SHOULDs and MUSTs? Where is the > interoperability issues within the protocol (not with readers that don't > know what the protocol looks like)? What are the potentials for causing > harm? I'm not saying there are none; I'm saying let's choose our levels > based on what we are supposed to be choosing from. If none of them are MUST, there is no social recourse when tracking down problems or seeking social understanding. Where did this feed come from? Who makes alternates? What's this all about? Robert Sayre From owner-atom-syntax@mail.imc.org Mon Apr 4 00:31:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25985 for ; Mon, 4 Apr 2005 00:31:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j344PQqf042090; Sun, 3 Apr 2005 21:25:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j344PQNp042089; Sun, 3 Apr 2005 21:25:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from afc.gov.au ([210.193.203.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j344POt4042080 for ; Sun, 3 Apr 2005 21:25:25 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.25.1] (HELO [192.168.45.41]) by afc.gov.au (CommuniGate Pro SMTP 4.2.9) with ESMTP id 2240151 for atom-syntax@imc.org; Mon, 04 Apr 2005 14:25:27 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 04 Apr 2005 14:25:16 +1000 Subject: Re: Why is alternate link a MUST? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/4/05 1:32 PM, "Paul Hoffman" wrote: > Not to pick on Eric; others have said things along the lines of: no offence taken. > This isn't a negotiating game. We have to have technical reasons for > our assigning requirements levels. I can't think of any MUST reasons for link[@rel='self'] or link[@rel='alternate']. For atom:id I can see how being able to clearly and unambiguously identify a feed would help us avoid requesting feeds from different URIs only to get the same information (that falls under "avoiding retransmission", right?). I can think of only one SHOULD reason for link[@rel='self'], which is the auto-subscribe interoperability problem with browsers. * hmmm.. link[@rel='alternate'] = MAY link[@rel='self'] = SHOULD id = SHOULD e. ps. I think it would be prudent to put the reason why something is a SHOULD in the spec itself. pps. I'm inclined to go the same way with atom:entry/atom:link's From owner-atom-syntax@mail.imc.org Mon Apr 4 05:28:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10397 for ; Mon, 4 Apr 2005 05:28:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j349KWcl047455; Mon, 4 Apr 2005 02:20:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j349KWaY047454; Mon, 4 Apr 2005 02:20:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j349KTFP047431 for ; Mon, 4 Apr 2005 02:20:30 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 97617 invoked by uid 17064); 4 Apr 2005 09:20:26 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.239.32]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 4 Apr 2005 09:20:26 -0000 In-Reply-To: References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <425059F2.6040709@cegetel.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/mixed; boundary=Apple-Mail-90--992245976 Message-Id: <5fc9a245d2322ebee4699ee1cf10187a@bblfish.net> Cc: atom-owl@googlegroups.com, Atom Syntax , Eric Scheid , Thomas Broyer , bloged From: Henry Story Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state Date: Mon, 4 Apr 2005 11:20:23 +0200 To: Henry Story X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-90--992245976 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Rereading my mail I found that I was perhaps not as clear as I could be. So here are a few improvements. > Ok. So let us try the slightly clumsy (to be improved later) definition > > What about: > [[ > The value "alternate" signifies that the IRI in the value of the href > attribute identifies a resource whose representations are an alternate > version of the representation described by the resource described by > the containing element. > ]] --Apple-Mail-90--992245976 Content-Type: image/jpeg; x-mac-hide-extension=yes; x-unix-mode=0644; name="Atom-related-2.jpg" Content-Disposition: inline; filename=Atom-related-2.jpg Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAFtAjEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoopCcUALRTDKo70nnJ6igCSio/ OT1FHnJ6igCSio/OT1FHnJ6igCSio/OT1FHnJ6igCSio/OT1FAlQ96AJKKQEHpS0AFFFFABRSUhk UdTQA6io/OT1FHnJ6igCSio/OT1FHnJ6igCSio/OT1FHnJ6igCSio/OT1FHnJ6igCSio/OT1FODg 9DQA6iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKpapq9lo0CTahOIY5H8tCVJ3NgkAAAnOAagXxJpbX7WYux56kggowXcB uKhsYLAZJUHIweKANSisWHxfok9vLcJfL5MUYmaRo3VShOAwJA3LnjIyBT/+Eq0cSQIbvBmVWXMT gAMcKWOMJk8DdjPagDXorPg13T7nUmsIpy1wu4YMbBWKnDBWI2sQeoBJHetCgAooooAKKKKACqV9 ceShNO1PU7TR9PlvtQmENrCAZJCCQuSB256kViXms2Gq2TS6be290gHJhkDY+uOlAGd4c8P6Xqeg 215eWaTXEwZ3kckljuPJ5rT/AOEQ0P8A6BsP6/40zwX/AMihp3/XM/8AoRrcrz5SfM9RGN/wiGh/ 9A2H9f8AGj/hEND/AOgbD+v+NOuPEUP2iS1023n1G6jYo6W4GyNvR5DhVI7jJPtWNZeKdTFpi4sl czS3cdtcNKBveJpCAVC8LtQjPJ+Xpzmhc/cDX/4RDQ/+gbD+v+NH/CIaH/0DYf1/xrHTxrfQ6ck0 2k+eYrO3ubl4pwOJSQNoI5PGccD39bD+I9Qkv7a3FmIbmO8eCe2WVXEo+zNKoDkDGcr6cg9qPf7g aH/CIaH/ANA2H9f8aP8AhEND/wCgbD+v+NTWOv2t5dC0lSazvSCRbXKbHYDrtPKuB6qTWnScpLqB jf8ACIaH/wBA2H9f8aP+ER0P/oHQ/r/jWzRS5pdwMjwfcb9As0yTsTaMnsCQK6KuQ8FMTpUI+v8A M111eihi0UUUwI5n2ITXDz2drrXizURexCZYbeAIGJwuTLnH1wPyrtL04gNcXpBz4q1nP/PG3/nL WVZ2g7CexY/4RbRv+fCL8z/jR/wi2jf8+EX5n/GtaqN/rFppzpFMzvcSAmOCJC8jgdwo5x7nj3ri 5pPqZ6lf/hFtG/58IvzP+NH/AAi2jf8APhF+Z/xrLuvEup2moXcjaZJ9ngsUungkmRWjUPJuORnL FVHy5xx1FSDxJfx313D9hjnB1BLS1CTbeDAJctlenf8A4ERzjmvf7j1ND/hFtG/58IvzP+NH/CLa N/z4Rfmf8ayJ/F13JpVzKLA2bNbXRglMquRLCDuyuMYyDg98cgVq/wDCQx2ZxqsE1nHxtuXAMLjs S44T/gWKXv8AcNR3/CLaN/z4Rfmf8aP+EW0b/nwi/M/41rUVPNLuK5k/8Ito3/PhF+Z/xpNASHS/ E2pWlqnlwGC3cRgnAYmTJ+pwPyFa9YVuxHji9H/Trb/+hS1tQk3PVlR3O5Q7lBp1RwcxCpK7Swoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAzdW06S/udLkQx7bS8Fw4fuPLkXjjrlx+VcyvhG6tbqZnRJbaO5uLxJWvZySX3sAIMhAwL kbucgdMnjXmaXxJqb2sTFNHtWKXLqxDXUoI/dg/3F53Hufl6Bs76IsaKkahUUYCqMACgDhLPw5q2 seH9OF0tnbrBpaW0SCRj5m4xMS4KjbgRAbeeSeeKu6v4Sur3XL2dFjlttQMRk3308Qi2gKQYkIWT IAIyRyT2rsKKAOa07Q9QtPEb3QENvatLK8ixXEjLPuyVPlMMRvyCzKeSDxzx0tFFAEN3aW9/bPb3 kEc8D8PHIoZW78g1l/8ACH6APuaVax/9c02fyxW1RQBi/wDCJaUPuJdx/wDXK+nT+Tij/hFrMfcu 9XX/ALilyf5ua2qKAOS8SeBk1bw7e2VtfX5nmjIj+030zR7uo3DJyOPQ1yGmfCWw8Nql3eXUt5ex kOu0mONGHIwByefU4PpXrlZOsxGSFgPSgDO8Ff8AIoad/wBcz/6Ea3K86tdX8QeH7COwgh0+aKHK ozo4YjJIzz15p3/Ca+JP+fLTvyk/xrilRm22B2F34esri4a6hElneNybi1by3Y/7XZ/+BA0xfDlo sNrHvmK2000y5YcmUOGB46fvGx+Fcl/wmviT/ny078pP8aP+E18Sf8+WnflJ/jR7GoB08XhO0jsZ bVrm6kWWCG3Z2KbtsRJTooGfmweO1Sz+G7ea/kvFuLmKd5jOGjK/K3k+TxlT/Dzz39uK5P8A4TXx J/z5ad+Un+NH/Ca+JP8Any078pP8aPZVAOuh8O2VukrQGVLuVCpvWfzJx9HfOPp09quNZu0zOLy5 AMqybAV2gBQNg+XO04ye+T1HSuF/4TXxJ/z5ad+Un+NH/Ca+JP8Any078pP8aPY1APQ6K88/4TXx J/z5ad+Un+NTW/i3xJOwH2XTV/4DJ/jS9hMRseCf+QXD9T/M119c14TsZbHTYIpmVpFX5mUYBJ5O B6V01dyGFFFRTXMFv/rpo4/99gP50AR3v+oNcXo//I1az/1xt/5y11V7qlk1s/l3ds7AEhRMuT7d a87TVryHWLq7sUhH2lI0aORC5GzdyCCP736VjWacbESktjuaqX2l2epBftcCuyfckGVdPdWHK/ga 5NvFPiEMQLTTyP8Adf8Axpg8W6+Tzb6aPwf/ABrmdKcdRNW3Oj/4R2BorxJbq7l+12v2R2kcFgmX xg46/OeTnoKcnh63S/8AtQmnz9oS5EeV271iMWemeVxkZ6gdOc84fFPiLPFpp5/B/wDGj/hKvEX/ AD6af+T/AONV7KoOzN+bwvZzWa2zSXAQC4GQwz++3b+3bccf1qb/AIR+zkn8288y8ZTlFuG3JH6b U+6MeuM+9c1/wlXiL/n00/8AJ/8AGj/hKvEX/Ppp/wCT/wCNHsagWZ1ws3DA/bLk4Z2wSuDu6D7v Re365qeGMwwRxtI8pRQpd8bmwOpwAMn6VxX/AAlXiL/n00/8n/xo/wCEq8Rf8+mn/k/+NL2ExcrO 4rj9X1gaF4mv71rO6ukS2t9yWyBmUZl+YgkccdagTxP4idsfZdPH4P8A41reH7e+udXn1C/8kSSx xxhIVIACljnk/wC1+laUqUoyuykmmZnh740Wur6/Bp8lgljZsGMl3cXIAQBSRkYwMkAde9ekWmp2 N+ubK8trgHvDKr/yNZ9j4V0iy1ttZtbKOG+kjMbvH8oYEgklemeOvWrN34f0i/bdeaXYzt6yW6Mf zIrqKNGisX/hEtKX/j3S6tfT7NeTRAfgrAUf8I9PH/x7a9q0PsXjlH/kRGNAG1RWL/Z+vRf6nXIJ P+vmxDf+gOlG7xLF/BpFz/wOWDP6PQBtUVnWF3qc05jv9NitlC5EkVyJVJ9OVU/p2qpdeLLK0vL6 3khuybHYsrrFlS7hdiKc8sxcAD1644yAblFc+3jC1UxxGxv/ALY85t/sYjXzQ+zzMH5tuCvOc496 VPGNg8sEYiu8yxPM+Y8CBUYq5kOfl2sCD+maAN+iufXxlY/ZpJZ7e8t8RpLGk0YVpkdgileccsQP mwRkZxWtp19/aFr5ptri2YMUaKdArqR9CQfqCRQBaooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKy/EN7NZ6ZssyBe3TrbWxIzh2/i9woyx9lNalYkv8Ap3jOFOsem2plPp5k pKqfqFST/vugDS0+xh0zT4LO2UiKFAq5OSfcnuT1J7k1Zoqm+rafEszSX9qiwcylplAj5K/NzxyC Oe4NAFyiqU2s6bbwxzT6haRxSAMjvOoVwe4JPNStqFmk3kvdQLLgtsMgDYAyTj0xzQBYorOm1Wwm 0t7uLVrWK1+6bpZUKKf945XP1qpF4dtruNZp9U1S9DjcsgvnjVge4ERRcfhQBuUVi/8ACLWqc215 qtu3quoTOP8Avl2Zf0pDaa9Yc2uoQalGP+WV7GIpD9JIxgfih+tAG3RWND4lt0mS31SCbTLhztUX IHlufRZASpPtkH2rZoAKimhEq4NS0UAY82jRykkqKh/4R+P+6PyreooAwf8AhH4/7g/Kj/hH4/7g /Kt6igDB/wCEfj/uD8qP+Efj/uD8q3qKAMH/AIR+P+4Pyo/4R+P+4PyreooAwf8AhH4/7g/KpItE jjOQoraooAggtxEAAKmJABJOAOpNLVLVcvbJbg4+0SLEf908t/46DSYMjj83Vf3hd4bM/cVDteUf 3ieoHoBz3z2qxDp9pb/6q2hUnqQgyfqe9WAAAABgDoKWiwrEbwxuuCin8Kxn0GxtPPn2rGHJd3c4 A/wFad3eiBlhiQy3LjKRg449Sew9/wCdMi0/fIs184uJhyoxhI/91f6nmhgYQ0z7Uf8AQ7f5D/y2 lBVfwHU/oPeoovBix36zNJvjAyVxj5v8K6+ik4p7hy33MH/hH4/7g/Kj/hH4/wC4PyreoqhmD/wj 8f8AcH5Uf8I/H/cH5VvUUAYP/CPx/wBwflR/wj8f9wflW9RQBhLoMYOdoq/baesHQVeooAQDApaK KACiiigAooooAK5/U/Ckep22qxSToft9xFcqHhDrG0axgBlJ+dSY+RxkEj3roKKAOL/4Ra+0680x 9OOnwzC7kmka3sBHBGvksoBRWDHPqWzk+nFaFp4PjhjnS5u2nF1azQXBCbS7SyM7sOTjlyAOccc1 0lFAHI2Xgh7OzuI0k0lJXhWFTFpSKjqGBPmgkl92MEAgdxzyNrw/o50PT2tvMRg0jSBI0KRxA4+V FJOFGOme56dK1KKAKeoXk9lGkkNhPeAnDrAyblHrhiM/gc+1QWXiLTr64Fss5huz/wAu1yhhl/BW AJHuMitOq19p9pqduYL62iuIjztkUMAfUeh96ALNFc9m48M3UKvPLc6PM6xBpmLyWjsQE+Y8shJx zkqSOSPu9DQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABWJ4c/0iTVb88/ab6RVP8A sxYiH4ZjY/jWnfXaWGn3F3L9yCJpW+igk/yqp4btHsvDenQS/wCuW3Qy+7kZY/8AfRNAGnXC3nhi 9SySaC2kSZdanvZlt/JMssbGUIw35QkBlOG9OxxXdVXvr6302ylu7uQRwxDLMf5AdyegA6mgDgrS wn0vWrRZNHuL6SSzvH+zyyQF08yZDzjagBzyFzjceoyalHg3UBoGowPGjXz2VnAswZcy+Wo8xATn AOCPmGDnmuo0i3vLq5bVdRDwySJsgtM8QRk5+bHVzgE9h0HcnYoA4IaFemGW7Npq/mvdRSKTLaCe PbGy+YI1UREfNtIJJI57AV1fh+C5tdCtYbyGKGdFIZI1VQOTjheAcYyBxnOK0qKACiiigCOaCK5h eGeNJYnGGR1DKw9CD1rG/sO60v5vD90Iox/y43JLwH2U/ej/AAyv+zW7RQBz83i+0023lbXYZdMl iQsVm5STAz+7kHysT2HDewp/hXxjpXi/T/tOmzfOuPNgfiSI+49PccVb8Q6LH4i0O60ueaWCK5UK zxEBgAQcDIPXGPoa4nT/AIU6N4Y1GHUbLUtWWeFg3EyBXAOSrALkqcYIz0oA9GLqO9J5i+tcb4e0 SDVNAsr27u9UeeeMO5GpXCgk+gD4H0FaP/CK2P8Az8ar/wCDS5/+LrB4iKdgOh8xfWjzF9a57/hF bH/n41X/AMGlz/8AF0f8IrY/8/Gq/wDg0uf/AIuj6xEDofMX1o8xfWue/wCEVsf+fjVf/Bpc/wDx dH/CK2P/AD8ar/4NLn/4uj6xEDofMX1o8xfWue/4RWx/5+NV/wDBpc//ABdH/CK2P/Pxqv8A4NLn /wCLo+sRA6HzF9aXzFPeud/4RWx/5+NV/wDBpc//ABdH/CLWQ/5edV/8Glz/APF0fWIgdGDmqd9/ x+ad/wBfDf8Aop6yvBt7JdeG7BppXlk8kBndizN7knkn3NauocTWD/3bkfqjL/WtnsJl2oLy5Fpb NLtLNwqIOrMTgD86nqjL/pGrwxfwW6GZh/tHKr+m/wDShgySytPsytJKwe4lwZZPU+g9AOwp815b wECWaNCecMwFPnfZGTXDm0s9V8X6o15aW9wY7a3VTLGr7eZemRUzlyRuGyOw/tWy/wCfqH/vsUf2 rZf8/UP/AH2K53/hH9I/6BVh/wCA6f4Uf8I/pH/QKsP/AAHT/CsfrK7C5jov7Vsv+fqH/vsUf2rZ f8/UP/fYrnf+Ef0j/oFWH/gOn+FH/CP6R/0CrD/wHT/Cj6yuwcx0X9q2X/P1D/32KP7Vsv8An6h/ 77Fc7/wj+kf9Aqw/8B0/wo/4R/SP+gVYf+A6f4UfWV2DmOi/tWy/5+of++xR/atl/wA/UP8A32K5 3/hH9I/6BVh/4Dp/hR/wj+kf9Aqw/wDAdP8ACj6yuwcx0X9q2X/P1D/32KnhuYZwTFIjgcEqQa5b /hH9I/6BVh/4Dp/hWK2taR4J1vVLidI7W2eC2ASCLG9/33AA7kDv6VcKym7WBSuekUV5R4d+MNz4 g8Yiwg0l2s3icQwxlTO7jnJLMqgYB4/U13n2nxDd/wCpsbKwQ/x3Mxmcf8ATA/8AH62KNuo52KW8 jL1VSR+VZH9g3V1zqetX0wPWK2Itk/Ap8/8A4+a0bLTrXT7X7PaxBIiSSCSxYnqSTkn8aAOIi1vx DJaaRD9pnlnvNPOoSS20NuCvCAIBIyjaNxLHqcjG0U8eI9Yltb3UZL6KD7FBaTGziSORZWkRSy7+ cgkkKVPXuRXYXWiaZfW8Fvd6daTQ24AhjkhVljAGMKMcDHHFVk8Nad/bE2pTWsE07sjRtJEpMO1Q o2nGR0zQBzdxreuJHlLiSX7Zq01jCsEMQeGOMynILkKXOwD5jjHYnq2fXtd/s6N2leLyBcGd7cW8 swCOAjyRhiNoGQ4Q53DjFdlPpdhc2j2s9lbyW8jmR4mjBVmJ3FiPXPOfXmoZfD+kTwW8MumWTxWw IhRoFKxg9QoxwKAL0MgmhSRWDK6hgR0INPrP1fUZNJtVu/s5mto2zcFT80UfdwMfNjqR1xkjOMG8 jrIiujBlYZBByCKAHUUUUAFFFFAGJ4xwfCWpRj/WTReTF/10chU/8eK1t1gzN/bfiKOBObLS3Ekz dpLjHyJ/wAHcfcp6Gt6gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAMXxb+90J7Mdb6 WO0x6rI4V/yTcfwrarE1H/S/FOk2o5W2WW9f2IXy0B+vmOf+A1tEgDJOAKAGyypBE8srqkaKWZmO AoHUk1hWMT+Ir2LVLtGWwhO6wgcYLn/nu49f7oPQc9TwxT/wl1wG5/sKJsr6Xzjv7xA/99n/AGR8 3R0AFFFFABRRRQAUUUUAFFFFABWLrjFYGx6VtVia9/x7t9KAKvg3/kT9K/691rYkkSKNnkdURRlm Y4AHuax/Bv8AyJ2lf9e61oalplpq9jJZ38Ilt5MblyRyDkEEcgggHivNl8TEZz+LtMA82NpprUOq PdxxnyELHAO84BGSMlc4zzVGXxqqXaPHY3c9k9m10piiBfaHI38sBtIAI7nI47VauvDVzd2jafLq 00umyFRLFLGDIyA8xiQEHB6EkE4zzRa+GZYYmSbUDMfsLWKs0WGCbiVJ55IBAPTOM8ZqvdAi/wCE yjju7tJLK5aGOaGGB4lDGYyJuXAz/nvSL40t54pRDaXkUgWZUa4iATzolJaM4bORtPTjg4NPh8KP DcxuL1TGklvLt8nktEmzru6EY7ce9LL4U82FI/tmNt1dXGfK6+csgx17eZ1747Zo90CxYeJrOcW8 N5J9lu5UVlWZDGspIB/dseG+gJNbNYD+Fvttqlnqt9Lc2UaLGLWNfKjYKAPnwSzdOm7HtWpFb3cb xj7TF5KyMdghx+7xhVB3cEHBz3xjAqXboBboqK2SaO2jW5lWWYKA8ipsDHuQuTj6ZNS1IHMeAWJ0 CzH+xXSarxaJJ/zznib8N65/TNcz4B/5ANp/uV0+rqTo93jqsTMPqBkfyr03sD2LtUbD95c3sx/i m8sfRQB/PdV1WDKGHQjIqnpHOnq/eSSRz+Lk/wBaOodSS9OIDXGaQc+KtZ/642/85a7O9/1Bri9H /wCRq1n/AK42/wDOWs6/wMJbG/WHB4gk1W6lg0e3R1gk2TTXEmwIQecIPnJ+oUe9blU7vSrK+mSa 4t1M0f3JVJWRfowwQPbNcKt1Mzlp/Eeo6jpl6sSwwz2NzBbSGOQjfN56g4IORGV9efmI7HNttV1d 9XsrOSa1R4tT+zzmONtsyG2aUcFsjuO/IB6ZB108N6XGqKlqFCIiDDsMhHDrnnkhhnJyeT6nMsmj 2Utx57RN5vnrc71kYHzFTYDwf7vBHQjOetVzR7DOah8Sa9Pa28qxaav2iwe+XIc7Qm3KnnkncOe3 PWrllquoy3Go3VtClxAJY2aGSfYyKYIm+QkbepJIOBz1rYj0SwiiijSDCRWzWqDe3ERxlev+yOev FRnw5pbEb7RXXIYo7MyEhVUEqTg4CqBkdvc0c0ewEmj6zba5Zm5tN+1XMbBh0YdRkZB69QSPer9V 5bKCZlLKw2RtGoR2UBWxngEDsMHqO2KdBaRW8jPHv3Miod0jNwuccE9eTz1PfNQ7CJqwYefG96Dy DawZH/Apa3qwYf8Akeb3/r1t/wD0KStsP8ZUdzp7Tw/pEV5HfxaZZx3iZ2zpAquMjB5Az0JH41q1 FB/qhUtdxYUUUUAFFFFABRRRQAhAIIIyD1FYehZ0q+uNCcnyol8+yJ/54E4Kf8Abj/dKVu1jeI7e VbeDU7RGe605/OCL1kjIxIg+q8gf3lWgDZoqK3uIru2iuLd1khlQOjr0ZSMgj8KloAKydb1GaExa fp206ld5EWRkQoPvSsPRcjjuSB34uanqEOlafLeXG4pGPuqMs7E4VVHckkAD1NU9E06a3Et9qG06 leYabByIlH3YlP8AdXP4kk96ALem6dDpVhHaW+4omSWY5Z2JyzMe5JJJPqat0UUAFFFFABRRRQAU UUUAFFFFABRRSE4FACO4QZNYMniSW6nki0WxkvvLYq85cRwqw6jeeWI/2QcdDiofEtzLcPa6VbSv FJfzeU0iHDJGAWcg9jtUgHsWFa1tbQ2VrFbW0SxQxKEREGAoHQCsatXk0W4Gb9v8S/8AQK0z/wAG L/8Axmj7d4l/6Bemf+DF/wD4zWvULXkC3yWZf/SHjaVUweVUgE56dWH51h7eYjO+3eJf+gXpn/gx f/4zR9u8S/8AQL0z/wAGL/8Axmteoby8gsLV7i5fZEmNzYJxk4HA9zR7eYzBtk8Sw6re376fpkkl yI0Uf2g48uNAcL/qefmZzn/a9qj1WLxPqwjt5rHTkss5niXUHBnHZS3lcL6jHPTOMg9JNcw25iE0 ioZXEaZ/iYgnA/I1JR7eYjHS88RxoqJpOlqqjAUai4AHp/qaG1/UrAb9V0hkgH3prOb7QEHqV2q2 PoprSivIJrqe3jfMsG3zFwfl3DI578VNR7ea3GSWt3DdwJNBIskcihkdTkMD0INT1yVki+H/ABI+ nwKI7G8ja5gjAwsbhgJFA7A7lbHqWrq0bcoNdcZKSugHUUUVQBRRRQAUUUUAFY+tRGSFgPStioZ4 RKpBFAHnNh4m1Xw/pVtp50a3nFsgjEgvWXdjvjy+PzqT/hYmp/8AQvw/+B5/+NV1VxoUcrElRUH/ AAjcf9wVk6MH0A5z/hYmp/8AQvw/+B5/+NUf8LE1P/oX4f8AwPP/AMaro/8AhG4/7go/4RuP+4KP Yw7Ac5/wsTU/+hfh/wDA8/8Axqj/AIWJqf8A0L8P/gef/jVdH/wjcf8AcFH/AAjcf9wUexh2A5z/ AIWJqf8A0L8P/gef/jVH/CxNT/6F+H/wPP8A8aro/wDhG4/7go/4RuP+4KPYw7Ac5/wsTU/+hfh/ 8Dz/APGqmg8earOwC6Bbj635/wDjVbv/AAjcf9wVLDoEcbZCij2MOwFXwbYy2GkW0E+3zEQBtpyM +xrpp4/Ot5Iz/GpX8xUVtbCFQAKs1qBV0yTzdKtJD1aFG/NRTNG/5A9p7xAmjR+NItl/upt/Lj+l Gj8aTbr/AHV2n8Dj+lSuhK6E10u6EivP9UttT07Vrm8024jTz0RHSSHf90tgg5H9416Ky7hiqVxp yTHkU2k1ZlHmp1vxODjzrT/wGP8A8VTTrviZRkz2YHvbH/4qvQToUWfuiqN7okN0/wBiiRTIQGdu 0S+v1PYVDpwS2JaRxa+IPEb523NmT6C2P/xVO/tzxP8A89rT/wABj/8AFV2Ol+ExYxSCZlkdmOCB /D2q/wD2FF/dFKNKNtUEVpqeff294l3bftFnu9Psx/8AiqX+3PE//Pa0/wDAY/8AxVbU2gaj/wAJ CGSCMKWLoC4wUUgH+Y/Oum/sKL+6KUYRd7oUdb6Hn/8Abnif/ntaf+Ax/wDiqP7c8T/89rT/AMBj /wDFV6B/YUX90Uf2FF/dFV7KHYqyOBTWvEzNgz2g/wC3Y/8AxVbfh6yvJNTmv7+ZJJpUSP5I9gAU sRxk8/Ma6RdDiB+6KuW9isPQVShFO6QWLUQxGBT6QDApaoYUUU122rk0ABYL1rIv/FWl6fObeS58 y4HJggRpZB9VQEj8qytUvrnWdUk0yzmeC1gA+1zxnDkkZESHsSDkt1AIxycixZ2Ntp0Ahs4EhjHO FGMn1Pqfc1hUrKDsiXKw4+MFP3NJ1Vh6/Z9v8yDSf8Jef+gPqv8A35X/AOKqeo5rmG32+fNHHuyF 3sBnAJOM+wJ+gNZfWJdhczGf8Jef+gPqv/flf/iqP+EvP/QH1X/vyv8A8VUyOsiK6MGVhkMDkEet Nmmjt4XlmkSONBuZ3YAKPUk9KPrEuwczMjSNfn0qW5tU0fU208t5lt+6XdFuJLR43fdB5HscdhnT /wCEvP8A0B9V/wC/K/8AxVT0UfWZdg5jGvNfmvtas5ZtH1P7FaAyqvlLl5jwpI3dFG4/Vge1aX/C Xn/oD6r/AN+V/wDiqnqE3duLZ7gzxCBN26TeNq7SQ2T0GCCD9KPrEuwczE/4S8/9AfVf+/K//FUf 8Jef+gPqv/flf/iqmZlTG5gMnAyeppaPrMuwcxB/wl5/6A+q/wDflf8A4qnDxjCnM+napCvdjaM+ P++M05Zo2meJZEMiAMyBhlQc4JHbOD+Rp9H1mXYOYu6brun6srGyuopinDqp+ZD6MvUH61oA56Vy moaRb37LKd0N3GP3V1Cdskf0PcexyD3FW/D2sT3DTWOo7BfWpAkKDCyqc7ZFHYHB47EEc4yd6dVT 06lJ3OhopAcilrUYUUUUAFMk4Q0+msMqRQBxt9MIvGWjvJ9xnlhBPZmQkf8AoOPxrqa5bxXpjXUB 2MyOrB43Xqjqcqw9wQDTNI8dWnlLb6+6WF6gw0jgiGX/AGlbouf7rEEdOetcteDb5kBY8bQXNxY2 KxDdai6Bu1Nu84Mexsbo0IZl37cgH3PANYEem3YslDi/MBsrpVeOzZWjVp4iqiMsW24BIQncVGMD pXWf8Jd4e/6D2lf+Bkf+NH/CXeHv+g9pX/gZH/jWKckrWEcZJZ3Rs7RGs44tLjupTIF0+eSGQmNN j/Z9wdVzvGOV3c981s3FvcyeAhpckd9NctArZMDo23zRgdWwwXHG4nAya2v+Eu8Pf9B7Sv8AwMj/ AMaP+Eu8Pf8AQe0r/wADI/8AGm2+wHN3egRWur7ItMf7BDqNvMirCzquY2Dsowf4tuSO/JqCy8KR Tf2YbvT528y1uzdbw/zPvTyw/wBAW2g9McdK6v8A4S7w9/0HtK/8DI/8aP8AhLvD3/Qe0r/wMj/x o5pAUPB0F5GJZL6KdJZLSz3NKpBZxEN3XuD1966asj/hLvD3/Qe0r/wMj/xqnqPj7QbG3d4b2O/k AJEVmwlJx6kfKv1JFS1KT2Aj16UN4u0iJD88UE8j+wYoB+eD/wB811dqcwjNeU6L4r0qfUp9S1XV 7QXVwRkB/ljQZ2oPYZPPcknvXq9qVa3RkYMrAEEHIIrupx5YpDJqKKKsAooooAKKKKACiiigApKW igBKKWigBKKWigBKKWigBKKWigAooqK6nFtaTTt0jQufwGaAK+j/APILhPrk/mTRpfyxXEPeK4kH 5neP0YVJp8BttOtoW+8kSq31A5qKP9xrEyH7txGJF/3l+Vv0KVPYXYvUUVXvLsWsYwpklc7Y4x1d v8PU9qoY29umh2w26h7mX7inoB3Y+w/+tT7S1W0h2hi7sd0kjdXbuT/nimWdoYN8szCS5l5kcdPZ R6Af/X71apLuIKKKKYylPxrFmfWKVf8A0A/0q7VK841HTz6u6/8AjhP9Ku0l1EgooopjCiiigAoo ooAKqX8hSEkelW6q3sfmQkUAcj4ZkDrqSn/WrfSGT15wV/8AHStbVcjqQvNC1htRsk8xXAW4gJwJ VHQg9mHOD36HsRsaZ4m0vVcJBcrHP3t5vkkH/AT1+oyPeuGtTak30IkjWrzue9827tZW1KZ9RE14 ZrYy5EBWKYLhf4cDGP72c816JSYAJIAyetZxlYk4q21GUa5Z+ZfPKWMCCGO5Kum6Nc7oSMOpJLbx yOfQ1kpqJufCqmLUp76a40eV75JJi4iYKu0kfwnJI7ZGTzjNel7Ru3YGcYzUFhZQ6dYQWluCIoI1 jTJycKMDJ+gquddh3OQutZlTxSnkXJU/bvs7RS3Z5GwgDyQMBS2CHJySR6iq39pzJ4f+02erXE1+ 8EZv0eUlbdmkQSEnB8oqC4wBwATj5a7/AAM5wKXA5460uddgucHDfyFIo7vVli0pr0obiG+eTbiL IjM7KuQW5yCeflz2p8VzE3w1vrcXO+Z4ryRS/wB91EzguR9SPzruNi7du0bfTHFLRz+QXOG1W3+z 30tpPfXb2sFzYz75blsoXd1Y7s8D5QcdAemKdZ29ze3dh5uqagFu57xJVS4KjajtsC4+7jA5HJ6d OK7eijnC5yvg65lvJ3uLhzJNJptkzuerH97kmuqopGYIpZiAo5JJ4FTJ3dxC1jLKB44UR9UsQJce 7/J/J/zqvqXjGxty0GnEahedAkLZRD/tv0H05PtT/C2nTiWS6u3Mt1cPvlkxjJ7ADsoHAHpXRQpu /Myoo7iI5jBqSmRDagFPrrLCiiigAooooAqXlos6EEVy2o+GVmYkLXaU0xq3UUAebN4PGfuD8qb/ AMIeP7g/KvSPIT0o+zx+lAHm/wDwh4/uD8qP+EPH9wflXpH2eP0o+zx+lAHm/wDwh4/uD8qP+EPH 9wflXpH2eP0o+zx+lAHm48Hj+4PyrQsfCqxsCV/Su48hPSnCJR0FAHlmtfBe01PWrS8sZVtYGlBv IccMvUlPRj0x05z2we6EGv6aAIZ7bVYF6JOPImA/31BRvptX61t9KWgDFXxTZwsI9Ujn0qQnGLxN qE+0gJQ/Tdn2rYR1kQOjBlYZBByCKzBr1lP4hl0IpI06weaxZR5bdMpnPLAMpIx0YVRn03QdO/0m 21BNH3SFN1vcrFGzg4IKHMZbOc/LmgDo6KxZfE2nWF99gvLlkmEscIeXaBIzqWGMew54HUVfGqWD S3EQvbYyWy7p0Eq5iHqwz8o+tAFuiqL65pceN+pWS7m2jM6DJyRjr1ypH1B9KlfUrKO9Fm95brdM u4QmVQ5HrtznFAFmisq18TaPdacl8mo2qWzyGJZJJVUFwSMcnrx+ValAC0UUUAFFFFABRRRQAUUU UAFFFFABVC/P2meGyXkORJL7Ip6ficD6ZqzdXSWkJkfJOcKq8l2PQD3qKxtniV5rjBuZjukx0X0U ew/xPek9dBPsW6p6jE5jS4hUtNbtvVR1YdGX8Rn8cVcqtd3i221FUyTv/q4l6t/gPU0MGNm1CGO1 jnTMvm48pE6yE9AP88UWlq6yNc3RDXLjHH3Y1/ur/U9/yAoW9u2k3f2m62Mk3Bdc7bdic4Geiknr 69evG1SWu4LXcKKKKoYUUUUAUr/i604+lwf/AEW9Xapaj/rbE/8ATyP/AEFqu0kJBRRRTGFFFFAB RRRQAUjLuGDS0UAY2paUtyp+UVx+p+D4rjIkhR19GUEV6QQD1qNoEbqKAPJf+EIROEjKD0ViB+lJ /wAIX7Sf99t/jXq5soz2FVdQey0uze5u2CRrgcDLMTwFUDkkngAcmiwHj/iHQzoWjy34tZrhYyNw WUjaD3PPT6etYfhDT7/xTdzXJUxWUHylULYdj0GSc8Dn8q9qs9Cl1Wdb/WYhGinNtYEgrF6NJ2aT 9F7ZPNaGm+HNO0e0+zafbJBDvZ9i9Mk5P+e3TpSsB5mfBoUEkOAOSTI3+NV7Tw1DeM6w+Ydnfe3P 6161d6Tb3VrJDLkIwwSpwfzrJ8O+HIrSJbtZHYXEQPlsOmeRz9Kl35lYl3ujhP8AhC/aT/vtv8aP +EL9pP8Avtv8a9W+wxego+wxegqrFHlP/CF+0n/fbf40f8IX7Sf99t/jXq32GL0FH2GL0FFgPKf+ EL9pP++2/wAaengaJ2BkgEmP7/zfzr1T7DF6ClFnGOwp2A4zSvCyQbcIAB0AFdbZWS26AAVbWJV6 CnUAFLRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHEQeG9ZiltNZaaRr77ebqax/ dYVZPkdd/crHj+IglBjtVjxBp+o30qLZ6bLBCY7mMmAW+8szDBYvkKjgFiQC3TODwevooA4Sz0LV I/sU81g5aKWyZ0MkZbCQsjn72OCc9eR0zVC38J6sNNmtJIL57iCzu41keS2WGV5FYDaVXe24kE7y MEc5r0qigDjdR8KGVNVS306EpJoa2dsBsA8zMpKj05ZDnp78VXvdK1qbWUlNnOUjv7ef90YBG8aq gLMxPmM/3hjIGB34z3VFAHnbeHdVha1c2l4UhS7gMdsbZiTJLvDYlyu1l4J4YY5GK7fRrNtP0Sxs 33bre3jiO595yqgctgZ6dcDPpTNR0n7ayywXl1Z3Kfdkgk+X/gSHKt+Iz6EVR/tq80f5fEEKCAcD ULcHyf8AtovJj+vK/wC0KAN6imxyJLGskbK6MMqynII9QadQAUUUUAFFFFABRRRQAVDc3UdpD5kp PXCqBksewA7mmXd6tsVRVMs7/ciXq3v7D3NMtrNxL9pu3ElwRxj7sY9FH9ep/SlfsIba20sk32u9 x5vIjjHSFT/Nj3P4D3vVXub2G02hyWkb7kaDc7fQf16VX+z3N/zeHyYD/wAsI25b/eYfyH5mjbYB 0l888jQ6eqyOpw8rf6uM/wDsx9h+JFS2tklrubc0kz/flf7zf4D2HFTxxpFGqRqqIowFUYAFOosF hrosiFHUMrDBBGQRWfGX0pxFKzPZscRyNyYfRW/2fQ/gfWtKkZQ6lWAKkYII4NDQWForNxJpP3Q0 lj6DloPp6r+o+nTQR1kRXRgysMhgcgihMLjqKKKYylqH+usR63I/9AartUr3m905fSZm/KNx/Wrt JCQUUUUxhRRRQAUUVna9qR0nQ7q8jXfKiYhT+/Ix2ov4sQPxoAt293b3au1tPFMsbmNzG4YKw4Kn HQjuKmrgdAgm8OTX2l6tt063urD7QJ4rncd8aBJpN20YYgo3TqCabqOuvD4qjMF6yLFfwW7pLekE xsqgkQAYKndnzGOcnjtQB3cNzBcqGgmjlUjIKOGBGcZ49walryiOabTrOS7sppEvDpX7sGZgAv2l hIwXkfKp3ZwcdcVo2txe3rW9pDq7fY5tSjiElnfvcsB5ErOnnMi5yVU8Z2k9uKAPRqx4NLdtQOqa xLG80WRbxqf3VsvQkZxlz3YjvgYGc87azXVtd2moNf30pfWbu1aFpSyGFfP2qE7kFAQevbOOK5+f VH1HSdRge+eSC40o3JH9oNM+9XUktgARttb5kXIAoA9aorzoapfP4naOLUYlZL6GG3ie/kJktiEy RCEIkDKWPmFuD3AU16LQBT1ZymlXOw4doyi/U8D9TVqNBHGqKMKoAA9qqan8y20X/PS4T/x07/8A 2WrtLqLqFFFFMYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUhGRg0tRSyiMZNAGPJo1xpMjXHh4oiE7pNPkOIZPUof+WbfT5T3Herul6z b6oJEQPDdQ4E1tMNssR9x6ehGQexNY9p4g1nUbZbqz0iBreQny2e92sQCRkjYcHj1qrqcGs6mY5W 0eCC7h/1N1DqG2SP6Hy+Qe6nIPcVHtI9wOyorlbK/wDFcdsEvdMsZpl48yO7KBx67dpwfxqf+0vE P/QGtf8AwP8A/sKPaw7gdHRXOf2l4h/6A1r/AOB//wBhR/aXiH/oDWv/AIH/AP2FHtYdwOjqnc3j +cbWzUPcYyxP3Yge7f0HU+3WsaXUPEjxMselWsbkcP8Abd2Pw2Uy2uNdtYfLi0e2XOSXN9uLN6n5 Bk/jSdWPcTNyOGDTYXmnlG9uZZ5Dy3+A9AKZ513ff8e6m2gP/LWRfnb/AHVPT6t+VYMT6+JhPc6T bXE4+6zX2An+6uzA+vX3q2NT8Q/9Aa1/8D//ALCl7SPcDatrKG03GNSXb78jHczfUmrFZ+jan/au m290Y/LaVMlN27ae4z3rQrUYUUUUAFFNZtozXO3/AIjvY9XmsdP09LkwxJJI73Hl43lgABtOfumk 2krsDpKz3gk092ms0LwscyW4/Vk9/Ud/r1xv7d17/oDW3/gd/wDYUf27r3/QGtv/AAO/+wqHUh3F dHSwTx3MKywuHRuhFSVxyajrkV208Wk26B/9Ygvchz2P3OD796sf27r3/QGtv/A7/wCwoVWHcLm5 cfNrFmvpHK/5bR/7NV2uQOq6414lx/ZFvuSNowv231IOc7P9kVN/buvf9Aa2/wDA7/7ChVIdxJo6 miuW/t3Xv+gNbf8Agd/9hR/buvf9Aa2/8Dv/ALCj2sO47o6miuW/t3Xf+gNbf+B3/wBhVvRtfnv7 26s72zW1nt0jfCzeYGV92OcDn5D+lUpxbsmFzeopAciiqGLSbRnOBmsq58TaXbTGBLkXNz/z72im aT8VTJH1OBVcxavrfFwX0ixPWONwbmQehYZWMf7pJ/2hQBLfa1I922n6NEl1fLxK7H9zbZ7yEd/R ByfYc1q28bRQIkjKzgfMyrtBPfA7Co7KxttNtUtrKBIYU6Igx9T7k9z3qxQAUm0DoBS0UAJtXcDg ZAxnFLRRQBSuvn1SxT+75kv5Db/7PV2qX39c/wCuVt/6E3/2FXaSEgooopjCiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACsnWJjHCxFa1Y evf8e7fSgCr4MOfCWnn1Q/8AoRrbrD8Ff8ihp3/XM/8AoRrZnEpt5BblBNtPllwSobHGQO2a82Xx MQ+iuE1Cz1ptPuxeJqMusmGQW88Em62B2nIRU27TtyAXGckANmq1no73GI4opm097y23QxWEtrGM B952u5bkFQxwAcDqc1XJ5gegPcwx3EUDyKJZQxRD1YDGcfTIqSvPZdDNvcqF02by4JL+K22wM3lh lBQLxwud2D07U+80iXS7PTLaxjlRtYtl0+5yTvDnDmQk85Cef+OKORdwO/ork/smopqR/wCEcju7 WAS/vvtz/wCjNz82yM5f6bdi9+a6AanGVVvIu/mWRv8Aj3fI2HBzx1P8I/iHIzUtAXKKbFIJYkkA ZQyhgGUgjPqD0NOqQMDwXKW0e3X0yP1NdVXH+Cf+QXD9T/M119emthi0UUUwILptsJNcbpshk8V6 wT2gtx+stdhe/wCoNcXo/wDyNWs/9cbf+ctZV/gYpbG/RRXNapBqb38rX4uZ9Kz8kenvsYDv5g4d v+ANz/drhSuZnS1HcXEVrA807rHEgyzN0ArhbKxvP7ZLuJVuhczMzLYybmgw2xTKX2lNpXCgZBA4 yCajn8PNFocUcWnzM02i5uVMbMXmUxFdwP8AHy+B17dqrkV9x2PQqK4uXSlht9Y1aK3ljmtrlLi2 Lqy/uY44mKqpxgEBlPv9KfDaTtZw3FvBqQ1a7DXJkhk2JGHYsqvuyh2jAxhiMdKOXzCx2NFZlneX VrZLHqqmW8jjDytawOY2yxAC8ckY5H44ANX4pxM0oCSL5b7DvQqCcA5Geo56j39KhoRJXNPZreeN bxXuLuJRawZWCdot3zSdSpB/WulrBh/5Hm9/69bf/wBCkrbD/GVHc34vCmmtGC7ag5/29SuW/m9P /wCEQ0M/63Topx6XBaUfk5NasH+qFS13FkNtaW9nEIrWCKCMdEjQKB+AqaiigAooooAKKKKACiii gClbfNqt8/8AdEcf5At/7PV2qWnfNJeyf37lv/HQq/8AstXaSEgooopjCiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACsTXQTA2PStuqN/b +dGRQBy/hDXtJtvC1jDPqljFKiFWR7hFZTuPBBPFbP8Awkmif9BjTv8AwKT/ABrm9Q8KRTys3koS TknaKof8IXH/AM8U/wC+a53h03e4HZ/8JJon/QY07/wKT/Gj/hJNE/6DGnf+BSf41xn/AAhcf/PF P++a4PxtqNtod2+lWUK/bFA82RkwI8gEAepwRz2/kvqy7ge3/wDCSaJ/0GNO/wDApP8AGoH1jw49 5HdvqemNcRqURzcplQeuOeK4yy8EhLC3WWNWkEahiV5JxzUWqeCS2nStbwKZ4x5kYC/eZeQPxxj8 aPq67gd//wAJJon/AEGNO/8AApP8aP8AhJNE/wCgxp3/AIFJ/jXDWvhS2vbSG5gjRopkWRDtHIIy Km/4QuP/AJ4p/wB80fVl3A7P/hJNE/6DGnf+BSf40f8ACSaL/wBBjTv/AAKT/GuM/wCELj/54p/3 zVqz8IRRuCYU/wC+RR9WXcDW8DkPo9u6EMrAsrA5BGTg119Zml2QtolUDAAwAK1K6QCiiigCtejM Brg7LULPT/Feri8u7e3Lw25XzZFTdzJ0ya9BmTfGRXJ6z4fS9cs8asfUrmpnHmjYTVx3/CQaP/0F bD/wJT/Gj/hIdH/6Cth/4Ep/jXPN4MjLf6lP++RSf8IXH/zxT/vmsPqy7i5Tov8AhIdH/wCgrYf+ BKf40n/CQ6P/ANBaw/8AAlP8a4y+8MCS7TTbONPtDrvlcKP3EfTd9T0A+p7Gr8XgeGGJY0gQKowP lo+rLuHKb91qugX0BgutR06WJuqNcJg/Xnke1Tf8JBo//QVsP/AlP8a8pMlqnxGOisI/IKiAcDHm 9fzydv1rtP8AhC4/+eKf980fVl3DlOi/4SHR/wDoK2H/AIEp/jR/wkOj/wDQVsP/AAJT/Gud/wCE Lj/54p/3zR/whcf/ADxT/vmj6su4cp0X/CQaP/0FbD/wJT/GszTrq3vvGd7LaTxTxi2gBaJwwzmT uKpR+DIw4Pkp/wB8iun0XRVsgAiKvrgYq4UVB3uCjY6OD/VCpKag2qBTq2KCiiigAooooAKKKKAC iiobuXyLOaX/AJ5xs35DNAEGkc6aj/8APVnl/wC+mLf1q7Vewi8jTraL+5Eq/kBVikthLYKKKKYw ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigApCAetLRQBGYEPUUn2eP+7UtZOr6pPBNHp+mRpLqU67lD/chTODI/sOw6seBjkgATVNRttOeO 3jhe6vphmG1ixvf3PZVHdjx+OBWVP4DsdeDXHiiGO7u3wFWNmVLdQchEIwTz1Y8t6AYA3NK0iHS0 kYO891Md1xcy4Mkre/oB2UcDtWhQBF9nj/u0fZ4/7tS0UAc/4dgS0l1DSWH/AB5zloh/0xk+dPwB Lp/wCtv7PH/drJ1L/QPEum3w4jug1jMfc/PET9CGX6yVt0ARfZ4/7tAgQdBUtFACBQOlLRRQAUUU UAJTWiVuop9FAEX2eP8Au1nazeJp0McdvCJ765by7aDON7dyT2UDknsPcgG3qWowaVYvdXJbYuAF UZZ2JwqqO7E4AHvVPRtOnWaTVNUCnUbhduwHK20fURKf1Y9z7AAAD9I0OPTLZvMfz7uZvMuZyMGV /XHYDoB2AAq/9nj/ALtS0UAefXnw78PR+ObK4e0kJuxPOzGdwftCujqQQfQyHHtXefZ4/wC7WT4m /cQWGoDrZXsUhPojkxOfoFkJ/CtugCL7PH/do+zx/wB2paKAIvs8fpTljVegp9FABRRRQAUUUUAF FFFABRRRQAVR1jnTJI/+exWL/vpgv9avVRvv3l1Yw+spkb6KpP8APbSewnsXqKKKYwooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKAEZgilmICgZJPasXwtGZ9PbV5gftOqEXLZ6rGR+6T22pjj1LHvWnfwNc6dcwIQGliZAT6kEVU 8NzrdeGdMmQYD2sZweoO0ZB9weKANOiiigAooooAztfsH1PRLm3gIW42iSBj/DKpDIfwYCptLv01 XSrW+iBVZ41k2nqpI5B9wePwq3WHon+garqmlHhFk+2W4/6Zyklh+Egk+gYUAblFFFABRRRQAUU1 nVMbmC5OBk4yfSnUAFMllSCJ5ZXVI0UszMcBQOpJp9Y2sWh1K/s7O6lij05jueJnw9045EeO6gAs R3wB0zkAh0yJ9dvk1m7Rlto8/wBnwOMYBGDMw/vMOg7KfVjW/UfnRef5HmJ5u3f5e4btucZx6ZqS gAooooAo65Y/2loV/ZDg3Fu8YPoSpAP507SL3+09Fsb7/n5t45v++lB/rVysXwh8vheyj7QhoR9E dlH6CgDaooooAKKKKACiiigAoopu9d+zcN2M7c849aAHUUUlAC0VBa3lteoXtLiGdFO0tE4YA+nF TEhQSSABySaAFqiv73W2Pa3gCj6ucn9EH51ZhuIblFeCWOVGUOrIwYFTyCMdj2NR2cDxPcSS43zS luOygBV/QA/jSYmWaKKazqgy7BRkDJOOScD9aYx1FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVg6Y39j6zPpMnEFyz3Vkx6 HJ3Sx/UMSw9m/wBk1vVR1bTE1Wy8kyNDKjCSCdB80Mg6MP6juCQeDQBeorL0bVXvPMtL5Fh1K2wJ 4h91gekieqNjj05B5BrUoAKKK42516//AOElijt7i4NlLfGyP7qJYlIjbIUk+YzhhnONvUUAdlWV qVnONY03ULSPe0TNBOoIGYXHJ/BlQ/Td61yWjX2qto0EC6xJALfTDemeSONzK29xtbI+4oUZxg/M Oakk1rX7vzbmG+S0UXdnbC3MCsE86OIvknklTISPcc5HQA76iuUivL6XQdRFzfLK9lLdQsZIUzcq qHaCBgAjIJwOcdOaxb2+vr/SWka9jgtrW70+3FmIlAk3GBy2eoOX4A4wvT0APRaz9fvPsHh+/usy jyoHYGLG8cdRnjI9+K0KKAPLvtgu/Nt7rUM21tqFjMjR6k84QM5Vj5p2kjIHsp6VcGqXG0Sw6rM+ qs94t/a/aCVgRElKkR5wm1hEAwAznknNeiBQBgAY6dKTCqS2AD3NAHm92t9aWd7Ous6mzW2jQago a4ODOS+Sf9nCD5Pu89K3fEV9NaahH/ZV1JPdefNvt9+QrizdkTHYHCtj1Oa3NE1GTVrA3rIqQTOx tsZy0WcKx/3sbh7EVo0AcN4UmtJvFQay1abUlOlq0jyTebtcuMjPY9Mr29Bmu5pAAvQAd+KWgAoo ooASsbwf83hWwk7TIZx9HYuP0ap/EU08OgXf2NWa6kTyYQozh3+VT9ASCfQA1ds7WOxsoLWEYigj WNB7KMD+VAE1FFFABRRRQAUUUUAFcL4pdrHxJe3UF1LBO2mxAMJT8sfnYlZVzjKoS3Tg813VJQBw Ime51GGy03WLuXSpNRijWeO7aRjm3leSMS5JI4Q9eCTjGBivbT/Y7OGfVtTvrizuI9RguxLMxHkx FlXAHRgq/eHJJPNejKoUAKAAOwpaAOI0K40q9N9qI1TTrMPBDELfTrpCbaNWJXeynG4lsdMAcAnq acmuyN4rjCXjLHLe3FrNFLekttWOQKPIxtjG5F2tnc2R616HSbR6DmgDyi2nm03TDLaXLxSzafpY lL3TRhISNruDg7BwAXC/LuJ4rY0uW+1C80+1bVZDZteThWtLt5d0axo2wzMqlwH3fMM8fLng126X Blv5YFUGOJBvY/3j0X8uT9RVgAKAAAAOgFAHntpfXenWNhqcuoajcNc2t40yGQyDCAsuxDwGGMD1 75rNlvReWt9a3OolrSGXTbkNHqbz7c3O2VjLhegCkgfKpwQRXqtJtAGABjp0oA8/0vVNSuPFarLf QrOdQniktWvXZvIXeFH2cR7VG0Iwk3c5HPzYr0Gk2jduwM9M0tABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAZmsaR/aKxz 20xtdQt8m3uAM7c9VYfxIcDI/EYIBBpOr/bzJbXMX2bUbfHn25OcZ6Mp/iQ9j+BwQQMrUPGn9nya kZbELb2dwlqs8lwqLLMwQgcj5VAfJY9Md+0Nt4z/ALSmt4tP0+3u75pZYCY7tWiQoiOSJQpypDjo M54IoA66qDaHpb3jXb6dZtcswcymFd5YEEHOM5GBz7CsT/hOF+aQ6fILeCyN5dyGUfuArSKyY/iY NGQMdeemOYIfiFbvaXTtDamaBYnxDerLEFkfbl5FHybTy3BwOmaAOgl8O6POkay6VYusbs6BoFIV mOWI47nr61aaxtWZy1tCS8iysTGPmdcbWPuNq4PbA9Kh0jUG1PTIrp4kjL54jmWVDgkZVxwQcZB4 +gq7QBkXv2G21Oyt59Ot2jvHlCzFF+WYpyCMdXTeM57Y71Yk0LSprqO5l02zeeNVVJGgUsoX7oBx xjt6Ua3px1XSpreNxHPxJBJ/zzlU7kb8GA/DIpdH1EatpUF3sMbuCssZ6xyKcOh9wwI/CgC9RRRQ AVjeKJHfTE0+Fis2pSraKV6hWyZCPcRq5+oFbNYk/wDpfjO1j6pY2bzsP9uVtiH8kl/OgDYjjSGJ Y41CogCqo6ADoKfRRQAUUUUAcLF4x1eSx0oyQW0dxqML3SmK1nuFjiUIMFUyxLFxzwFHqesreLdY ktbu8SztraGwsYr25huVcSnIcug6bSAhwSO449N+XwzpstnZ2wiliSzTy7dobiSN41IAK71YNggD IJ7D0rGm8O6RF4iW2ljd1ubeKKK0gkdVWKLdkyAMAyZZR82eeOcmgBl54t1K3W6kEFv5Rv8A7Ba7 YpZXLY3F2VeSAoPygZJHUU2fxZqyabHMbMW+2SVJbmaxn8v5dpQ+Xw6KwY/MchSp610c+g6fcWss DwsEln+0EpIysJc53qwOVPHYiq58KaWYYoxHcIY9/wC8S6lWR9+N+9w25s4Gck9B6UAaltN9otYp gUPmIGyjbl5GeD3HvUtRwwx28EcMKBIo1CIq9FAGABUlABRRRQAUUUUAFFFFABRRRQAVBeXItLZp SpYjhUHVmPAA+pqZmCqWYgADJJ7VQtwdQuRduD9njz9nU/xdi/8AQe3PekxMnsbY21ttkYNK5Lys P4mPX8Ow9gKs0UUxhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBkXPhu1uYbtPOnje5ulvBKhXdFKoQKVyMfw Dgg5ye1ULnwxdvqGnSxare7oWneW6LIZAzqqgBSuwLgdAuO/XmumooAw4PCOnQWs9t++khuLMWcq u+dyZdi2cZ3EyMSfyAqCbTI7JVgu/EGpLcXLIlvPI6LtKnIUAIEJOTkMCW/AY6Oobu0gv7WS2u4U mgkG10cZBFAFfSdKh0eyNvC7vukeV3cKCzMSScKAByegAq9XPC4uvC52X0kl1pH8F02WktR6S92T /b6j+L+9W+jrIiujBlYZDA5BHrQA6sKL/iT+KHiPFpq2ZI/RbhV+Yf8AAkAb6ox71u1n65prappc kMLiO5QiW3lP/LOVTlT9MjkdwSO9AGhRVLR9SXVtLhuwhjdgVkiPWORTh0PuGBH4VdoAKxdJ/feI 9en/AOeckNqPosQk/nMa2qxfDvzS6xJ3fUZM/wDAVRP/AGWgDaooooAKKKztZ1hNItkIhkurqZvL t7WIjfM3oMkAAdSTwACaAF1fVV0yFFSM3F5OSltbKcNK39FHUt2H4CmaPpTWCy3F3IJ9QuiGuJgM A46Io7IvQD6k8k03SNJkt5pL/UXWfU51w7r9yJOojjz0UevVjyewGrQAUUUUAFFFFABRRRQAUUUU AFFFFABTJZUhiaSV1RFGWZjgAVVk1JDI0VojXMwOCE+6p/2m6D6dfakjsXlkWa/kEsinKxrxGh9h 3PufwxSv2FfsRhJNVfMyGOxByqNw03uw7L7d+/odGlooSCwUUUUxhRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFACEZGDyKwHsLrw67T6PE0+nk7pdPXrH6tDnp7p0PbB4PQUUAVrDULbU7RLmzlEsTc ZHBBHUEHkEHgg8irNY1/o80V2+paK6Q3rY86J+IroDs+Ojejjkd8jirOlavDqiSKqvBcwnbPbS8S Qt7juD2I4PY0AUh/xJvE5XpZ6scj0S5Vef8AvtFz9UPdq3ao6zpo1XS5bYOYpTh4ZR1ikU7kYfRg DTdF1L+1NMinkQRXAJiniz/q5VOHX8CDj1GDQBoVi+GObbUD66jc/pIR/StkkAZJxWN4W5026fs+ oXhH4XEg/pQBtUUVnavq66ascUMRub64JW3tlOC5HUk/wqO7dvckAgC6rq8emJGgja4u5zst7aP7 8rf0UdSx4AqLSdIkt5nv9RkW41OZdryKPkiXr5cYPRR+bHk9gF0nSGs5JLy+lFzqU4AlmxgKvaNB /Cg9Op6nJrUoAKKKKACiiigAopskiRLukdUUd2OBVQ6vZE4im88+kCmT/wBBBpXQXLtFUfttzJ/q LCX/AHpnVB/U/pR5epS/emt4B6RoXP5kgfpRcVy9VafULW2fZLOgk7IDlj/wEc1F/ZaSf8fNxc3H s0m1f++VwPzqzBawWqbbeGOJfRFAo1DUrfbLqf8A49bNlX/npcHYP++eW/MCj+znuOb64eYf880+ SP8AIcn8SavUUW7hYZHGkMapEioijAVRgCn0UUxhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUU1mCjJrEu9fkkvHsdItTe3aY8z5tkUOem98HB9gC3tjmgDcyKNw9awRpWu3PzXetR22f8A lnZ2w+X23Sbs/XaPpS/8I5e/9DNq/wD37tf/AIzQBu7h61marpCX7x3VtN9l1GEYhuVGSB/dYfxI e6n6jBwaq/8ACOXv/Qzav/37tf8A4zR/wjl7/wBDNq//AH7tf/jNAFnS9Z+0zNY38a22pxLueEHK uucb4z/Ev6jODivIJbLxD4e+L+kza5dNdQ3N6PKuUUJHIWAjztHCtjAI68dxg16bd+DJL5oXn8Ra s0kDiSJwlsGRvYiEH2I7jg1JceEZbtUW58QanKI5FlTfDaHa6nKsP3PBB70AJ8QtOGreAtYturC3 MqgdSUw4H/jtcr8EtAuNP8PS6reTTD7acQQs52rGD97b0yTn8Bx1rr38M3ciMj+JNWZWGCDHakEf 9+abD4WuLeFIYPEWqRxRqEREitAqqOAABDwKAL+r6wmmRRpFGbi9uDstrZTgyN3JPZR1Ldh74Bj0 bSmst93fypcapcAfaJwMKPREB+6g7Dv1OSTWeng2SO/kvR4i1c3MiCNpCtsSFHYZh4HfAxk1Y/4R y9/6GbV/+/dr/wDGaAN3cPWjcPWsL/hHL3/oZtX/AO/dr/8AGaG8NXLxPHJ4j1dt3QgW6lfoViFA GvPe21qAZ54489AzAE/Qd6g/tIy/8etpczD+8V8tf/HsH8gayYPCdzZkta6/fBz1aWC3bP1IjBP5 09pvEGlDfcQwapbj7zWqmKZR/wBc2JDfgwPoDS1Fqaf/ABMpe1rbj/gUp/8AZR/Oj+znk/4+L25k 9kYRj/x3B/WnadqdtqlolxayB42yM4wQQcEEHkEHgg8g1cosFinHpVlG24W0bOP43G9vzOTVsAAY HApaKdhhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUh6GgDA8U 6hPbaa0dm4S6uHS3hcjOx5GCK2O+C2fwrV03TbbSbJbWzj2RgljklizE5ZiTySSSSTXM+MVnNoJL dQ01vLHcRqTgM0bhwD9SuPxrpdJ1W11rTor2yk3wyD6FSOqkdiDwRQBcrMfxFpcdnFdvdqIJrZrp HKtgxLt3N07b19+a064NvB+s3GlRafM2nrFa6VcafEyyuxkL+WFdhs+UYj5Az170AdA3jPQkKBr7 G9VYHynwFZioYnbwpIPzHjpzyK0P7VsxfCzMw+0GXygm08vs8zGcY+7zWRq/h25vxr/kvAp1Gxjt odxI2svmctgcD5x0z3qfVrLVLm/s7u1is3NjdGSJJJmTzI2iZGyQh2sGY4wCCB2zwAXI9d06USFL lSI43lf5TwqMVY9OzKR+FVn8T6fAs8lxOixJMkUZQO7yFo1kA2Bc5wc4GeBnjkDBj8La5a2RSFtP knuLS4tpmaV1WMySs6uvynd985Bx9ani8M6nYXqX9t9knminR1hklZFZPsyQt8204YFcjg8emaAN fSvElrqlhHcoDmb7Q0SR5cyJFIULDjv8px/td6itvE0l7oxvbXS7l5jdPapbNhW3K5Ulz/CPlJPX HTmpPDunahpOnW9pci0Yb7iSZombhnlLoFBHIwxznGMDGapTaNrFvolza6fLbia41Cadz57RfuXk Z8BwjFWwQM445wehoAni8S3N0FitNJllulllimUyhY4jHt3fvMYOdwwMZPPTBxXj8ax3c9lHZW8J N1bRXCi5ulhbEhYBVGDuPyHp7etQXOiavJp1nY2+m6XBYRl/tFnHqMqibptzIIckElywxzxknkF2 r+Hr/VLOa1GnaNEl3bJA0iud9rtJ+4fLG8AEFfu4NAHW0VUDX4kA8q28vz8Z8xt3lbev3fvbuMdM c5zxU1sZzbqbtYkm53CJiyjnsSAentQBLRRRQBzWpxLoviOzvrcBItSkNvdIOjSBCySfXCMp9cr6 V0UTb0BrkvEOox6l4jsdNtmDiwlNzcsOivsKon1w5YjthfWuotM+SM0AWKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAy9VsvtERGK4OW01PQNQku9HnMDu cyRsu6KX/eX19wQfevTmUMMGqN1psc4OVFAHI2/xJuoRt1LRHLAcvaTBgx/3X24/M1P/AMLSse+i 6x/3zB/8drQn8NxufuCqp8LR/wBygCH/AIWlY/8AQG1j/viD/wCO0f8AC0rH/oDax/3xB/8AHal/ 4RaP+5R/wi0f9ygCL/haVj/0BtY/74g/+O0f8LSsf+gNrH/fEH/x2pf+EWj/ALlH/CLR/wBygCL/ AIWlY/8AQG1j/viD/wCO0f8AC0rH/oDax/3xB/8AHal/4RaP+5R/wi0f9ygCL/haVj/0BtY/74g/ +O0f8LSsf+gNrH/fEH/x2pf+EWj/ALlH/CLR/wBygCL/AIWlY/8AQG1j/viD/wCO0f8AC0rH/oDa x/3xB/8AHal/4RaP+5R/wi0f9ygCFvifbMP3OiaoW7eZ5Kj9HNZ914q8Q64DDbRRaXA3DNGxlmI9 mIAX8AT6GtuPwxGD9wVp2uiRw4+UUAY/hvQlsowFU8ksSTksTySSeST6muvjXYgFNigWIYAqWgAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooATFGB 6UtFACbR6UbR6UtFACbR6UbR6UtFACbR6UbR6UtFACbR6UbR6UtFACbR6UbR6UtFACYHpS0UUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAf/2Q== --Apple-Mail-90--992245976 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit In this new graph I have now shown the consequence of the relation defined above as little arrows between the entry representations and the html and xhtml representations. It is not clear exactly which of the green arrows should be named tom2:alternate, the one between the entry id and the displaced resource or the little ones which relate the representations. In any case the argument still holds: we have a relation that I had argued before is too strong. It relates things we don't really want to relate, namely the yellow entry and the green representations. > [snip] > Now I can hear you think (amazing powers that I have :-) that what > you really mean is > that the green entry representation alone (not the older yellow one) > is an alternate version > of the representation of the resource. But if you > mean to say that, then > why bring the id of the entry into the picture at > all? > > Let us just cut it out, since the link construct can indexically refer > to the representation > in which it is located. let me call the following relation tom:alternate > > [[ > The value "alternate" signifies that the IRI in the value of the href > attribute identifies a resource whose representations are an alternate > version of the containing element. > ]] > > Now I think we have another way of saying what I meant by the > A:alternate relation. > Which of the phrasings is better, the one above or > > [[ > The value "alternate" signifies that the containing element is an > alternative > representation of the resource identified by the IRI in the value of > the href attribute. > ]] > > is now a matter of which one is clearer. But I think we are describing > the same relation. On closer thought we are not. The intent of tom:alternate is to describe a relation between representations, shown in the diagram below as little unlabeled green arrows. Just as in the previous definition it is not clear whether the definition above relates the representation and the resource, or whether it is trying to identify the consequences of the relation (the unlabeled arrows). --Apple-Mail-90--992245976 Content-Type: image/jpeg; x-mac-hide-extension=yes; x-unix-mode=0644; name="Atom-alternate-link-3.jpg" Content-Disposition: inline; filename=Atom-alternate-link-3.jpg Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAFtAjEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoopCcUALRTDKo6mk85PUUASUVH 5yeoo85PUUASUVH5yeoo85PUUASUVH5yeoo85PUUASUVH5yeooEyHvQBJRSAg9KWgAooooAKKSkM ijqaAHUVH5yeoo85PUUASUVH5yeoo85PUUASUVH5yeoo85PUUASUVH5yeoo85PUUASUVH5yeopwc HoaAHUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRVLVNXstGgSbUJxDHI/loSpO5sEgAAE5wDUC+JNLa/azF2PPUkEFGC7g NxUNjBYDJKg5GDxQBqUViw+L9Ent5bhL5fJijEzSNG6qUJwGBIG5c8ZGQKf/AMJVo4kgQ3eDMqsu YnAAY4UscYTJ4G7Ge1AGvRWfBrun3OpNYRTlrhdwwY2CsVOGCsRtYg9QCSO9aFABRRRQAUUUUAFU 7248lCaXU9TtNH0+W+1CYQ2sIBkkIJC5IHbnqRWLd6zYatZNLpt7b3SAcmGQNj646UAZvhvw7pWo eHLG7u7NJp5og8kjkksT1J561p/8Ihof/QNh/X/Gk8G/8ifpX/XutbVedKTu9RGN/wAIhof/AEDY f1/xo/4RDQ/+gbD+v+NOk8RQyXLW2mW8+ozI5SQwACOMg4IaQ4XI7gEn2rAtvFuqrofmT2SmaS2u JLe4aUDe0eSdyBflGOR1zjnGaa531A3f+EQ0P/oGw/r/AI0f8Ihof/QNh/X/ABrLk8Y3ttCzPo/n eQtuJ2juB96bAUKCOeSM5xxUg8SahNqFvClnsnjmnhuLVJVYSMsauu1yB2cHt6Gj3+4Gh/wiGh/9 A2H9f8aP+EQ0P/oGw/r/AI1PYa9aX1z9lImtr0KWNtcoUkwOpHZh7qSPetKk5SXUDG/4RDQ/+gbD +v8AjR/wiOh/9A6H9f8AGtmilzS7gYngm6aXwzp4ZixEIGScniumri/ALH+wbMf7H9a7OvSGLRRR QBHM+xCa4eeztda8WaiL2ITLDbwBAxOFyZc4+uB+VdpenEBri9IOfFWs5/542/8AOWsqztB2E9ix /wAIto3/AD4Rfmf8aP8AhFtG/wCfCL8z/jWtVG/1i0050imZ3uJATHBEheRwO4Uc49zx71xc0n1M 9Sv/AMIto3/PhF+Z/wAaP+EW0b/nwi/M/wCNZd14l1O01C7kbTJPs8Fil08EkyK0ah5NxyM5Yqo+ XOOOoqQeJL+O+u4fsMc4OoJaWoSbbwYBLlsr07/8CI5xzXv9x6mh/wAIto3/AD4Rfmf8aP8AhFtG /wCfCL8z/jWRP4uu5NKuZRYGzZra6MEplVyJYQd2VxjGQcHvjkCtX/hIY7M41WCazj423LgGFx2J ccJ/wLFL3+4ajv8AhFtG/wCfCL8z/jR/wi2jf8+EX5n/ABrWoqeaXcVzJ/4RbRv+fCL8z/jSaAkO l+JtStLVPLgMFu4jBOAxMmT9TgfkK16wrdiPHF6P+nW3/wDQpa2oSbnqyo7ncodyg06o4OYhUldp YUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAZuradJf3OlyIY9tpeC4cP3HlyLxx1y4/KuZXwjdWt1MzokttHc3F4krXs5JL72AEGQ gYFyN3OQOmTxrzNL4k1N7WJimj2rFLl1YhrqUEfuwf7i87j3Py9A2d9EWNFSNQqKMBVGABQBwln4 c1bWPD+nC6Wzt1g0tLaJBIx8zcYmJcFRtwIgNvPJPPFXdX8JXV7rl7Oixy22oGIyb76eIRbQFIMS ELJkAEZI5J7V2FFAHNadoeoWniN7oCG3tWlleRYriRln3ZKnymGI35BZlPJB4546WiigCG7tLe/t nt7yCOeB+HjkUMrd+Qay/wDhD9AH3NKtY/8Armmz+WK2qKAMX/hEtKH3Eu4/+uV9On8nFH/CLWY+ 5d6uv/cUuT/NzW1RQByXiTwMmreHb2ytr6/M80ZEf2m+maPd1G4ZORx6GuR0v4SWHhtY7y9upby9 jIddpMcaMORgDk8+pwfSvW6ytYiMkLAUAZ/g3/kTtK/691rarzu11jxBoGnwWEMOnzR267EdkcEg dM89aX/hNfEn/Plp35Sf41xOjNsDsJ/D1lJdNdW3mWV0zbmmtW8suf8AbH3X/wCBA1D/AMIvZGzt rZnnMdvHLGvzDLCQENnj34xXK/8ACa+JP+fLTvyk/wAaP+E18Sf8+WnflJ/jR7KoB1KeF7YW0kMl xcyGVrdndioJMJUr0UDnaM8flTpPDVu15LdR3N1DNJM826Nl+VmjVDjKnsg/EmuU/wCE18Sf8+Wn flJ/jR/wmviT/ny078pP8aPZVAOvg8PWVqkhtfMiuZAA93u8ycjOcF3yce3T0q39jfzd/wBsuced 5u3K4xt27Pu/d/i9c98cVwv/AAmviT/ny078pP8AGj/hNfEn/Plp35Sf40exqAeh0V55/wAJr4k/ 58tO/KT/ABqa38W+JJ2A+yaav/AZP8aXsJiNPwD/AMgK0/3P612lcv4Q06TTtKtreRg7xoAzAYBP sK6mu4YUUUUAVr3/AFBri9H/AORq1n/rjb/zlrrdX1C1sbfN1OkeRwpPJ+g61wMtxqNrqFxqelpA 0V3GilLhGyNhfkYPfdWdVc0XFbieuh2FVL7S7PUgv2uBXZPuSDKunurDlfwNckfFPiIHH2TT/wAn /wAaP+Eq8Rf8+mn/AJP/AI1y+wmRys6H/hHYGivEluruX7Xa/ZHaRwWCZfGDjr855OegpyeHrdL/ AO1CafP2hLkR5XbvWIxZ6Z5XGRnqB05zzn/CVeIv+fTT/wAn/wAaP+Eq8Rf8+mn/AJP/AI0/Y1B2 ZvzeF7OazW2aS4CAXAyGGf327f27bjj+tTf8I/ZyT+beeZeMpyi3Dbkj9NqfdGPXGfeua/4SrxF/ z6af+T/40f8ACVeIv+fTT/yf/Gj2NQLM64WbhgftlycM7YJXB3dB93ovb9c1PDGYYI42keUooUu+ NzYHU4AGT9K4r/hKvEX/AD6af+T/AONH/CVeIv8An00/8n/xpewmLlZ3Fcfq+sDQvE1/etZ3V0iW 1vuS2QMyjMvzEEjjjrUCeJ/ETtj7Lp4/B/8AGtbw/b31zq8+oX/kiSWOOMJCpAAUsc8n/a/StKVK UZXZSTTMzw98aLXV9fg0+SwSxs2DGS7uLkAIApIyMYGSAOvevSLTU7G/XNleW1wD3hlV/wCRrPsf CukWWttrNrZRw30kZjd4/lDAkEkr0zx161Zu/D+kX7brzS7GdvWS3Rj+ZFdRRo0Vi/8ACJaUv/Hu l1a+n2a8miA/BWAo/wCEenj/AOPbXtWh9i8co/8AIiMaANqisX+z9ei/1OuQSf8AXzYhv/QHSjd4 li/g0i5/4HLBn9HoA2qKzrC71Oacx3+mxWyhciSK5Eqk+nKqf07VUuvFllaXl9byQ3ZNjsWV1iyp dwuxFOeWYuAB69ccZANyiufbxhaqY4jY3/2x5zb/AGMRr5ofZ5mD823BXnOce9KnjGweWCMRXeZY nmfMeBAqMVcyHPy7WBB/TNAG/RXPr4ysfs0ks9veW+I0ljSaMK0yOwRSvOOWIHzYIyM4rW06+/tC 18021xbMGKNFOgV1I+hIP1BIoAtUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFZfiG9ms9M2WZAvbp1trYkZw7fxe4UZY+ymtSsSX/TvGcKdY9NtTKfTzJSVU/UKkn/fdAGlp 9jDpmnwWdspEUKBVyck+5PcnqT3JqzRVN9W0+JZmkv7VFg5lLTKBHyV+bnjkEc9waALlFUptZ023 hjmn1C0jikAZHedQrg9wSealbULNJvJe6gWXBbYZAGwBknHpjmgCxRWdNqthNpb3cWrWsVr903Sy oUU/7xyufrVSLw7bXcazT6pql6HG5ZBfPGrA9wIii4/CgDcorF/4Ra1Tm2vNVt29V1CZx/3y7Mv6 UhtNesObXUINSjH/ACyvYxFIfpJGMD8UP1oA26KxofEtukyW+qQTaZcOdqi5A8tz6LICVJ9sg+1b NABUU0QkGDUtFAGPNo0cpJKiof8AhH4/7o/Kt6igDB/4R+P+4Pyo/wCEfj/uD8q3qKAMH/hH4/7g /Kj/AIR+P+4PyreooAwf+Efj/uD8qP8AhH4/7g/Kt6igDB/4R+P+4PyqSLQ40OdoraooArwW4hAA FWKKKACq9zeRWgUSEl3+5GgyzfQUy7unR1t7VQ9y4yM/djX+83t7d/zIda2SW25yTJO/35X+83+A 9hxSv2Ec5q3hWfWbv7Z+6tXcgPGSWO31JHG7GOBx71sSaREY1jRAEUBVHoBWpRSUUncFFLUwToEZ P3RR/wAI/H/cH5VvUVQzB/4R+P8AuD8qP+Efj/uD8q3qKAMH/hH4/wC4Pyo/4R+P+4PyreooAwf+ Efj/ALg/Kj/hH4/7g/Kt6igDCXQYwc7RV+209YOgq9RQAgGBS0UUAFFFFABRRRQAVz+p+FI9TttV iknQ/b7iK5UPCHWNo1jADKT86kx8jjIJHvXQUUAcX/wi19p15pj6cdPhmF3JNI1vYCOCNfJZQCis GOfUtnJ9OK0LTwfHDHOlzdtOLq1mguCE2l2lkZ3YcnHLkAc445rpKKAORsvBD2dncRpJpKSvCsKm LSkVHUMCfNBJL7sYIBA7jnkbXh/RzoentbeYjBpGkCRoUjiBx8qKScKMdM9z06VqUUAU9QvJ7KNJ IbCe8BOHWBk3KPXDEZ/A59qgsvEWnX1wLZZzDdn/AJdrlDDL+CsASPcZFadVr7T7TU7cwX1tFcRH nbIoYA+o9D70AWaK57Nx4ZuoVeeW50eZ1iDTMXktHYgJ8x5ZCTjnJUkckfd6GgAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACsTw5/pEmq355+030iqf9mLEQ/DMbH8a0767Sw0+4u5fuQR NK30UEn+VVPDdo9l4b06CX/XLboZfdyMsf8AvomgDTrhbzwxepZJNBbSJMutT3sy2/kmWWNjKEYb 8oSAynDenY4ruqr319b6bZS3d3II4YhlmP8AIDuT0AHU0AcFaWE+l61aLJo9xfSSWd4/2eWSAunm TIecbUAOeQucbj1GTUo8G6gNA1GB40a+eys4FmDLmXy1HmICc4BwR8wwc811GkW95dXLarqIeGSR NkFpniCMnPzY6ucAnsOg7k7FAHBDQr0wy3ZtNX817qKRSZbQTx7Y2XzBGqiIj5tpBJJHPYCur8Pw XNroVrDeQxQzopDJGqqByccLwDjGQOM5xWlRQAUUUUARzQRXMLwzxpLE4wyOoZWHoQetY39h3Wl/ N4fuhFGP+XG5JeA+yn70f4ZX/ZrdooA5+bxfaabbytrsMumSxIWKzcpJgZ/dyD5WJ7DhvYU/wr4x 0rxfp/2nTZvnTHmwPxJEfcenuOKt+IdFj8RaHdaXPNLBFcqFZ4iAwAIOBkHrjH0NcVp3wo0bwxqM Oo2Wpass8DhuJkCuAclWAXJU4wRnpQB6LvUd6PMX1FcZ4f0SHVNAsr27u9UeeeMO5GpXCgk+gD4H 0FaP/CK2P/Pzqv8A4NLn/wCLrB4iKdgOi8xfUUeYvqK53/hFbH/n51X/AMGlz/8AF0f8IrY/8/Oq /wDg0uf/AIuj6xEDovMX1FHmL6iud/4RWx/5+dV/8Glz/wDF0f8ACK2P/Pzqv/g0uf8A4uj6xEDo vMX1FHmL6iud/wCEVsf+fnVf/Bpc/wDxdH/CK2P/AD86r/4NLn/4uj6xEDovMX1FG9fWud/4RWx/ 5+dV/wDBpc//ABdH/CLWX/Pzq3/g0uf/AIuj6xEDo85pk8yW1vJNIcJGpZj7CsHwbfSXXhuwaaV5 ZPJAZ3YszY7knkn3rU1H969rbdpZgW/3V+b+YA/Gtm9BMfp0Dxwmacf6TP8APL7ei/QDj/8AXVui imtBiVDNeW8BAlmjQnnDMBT532Rk1w5tLPVfF+qNeWlvcGO2t1Uyxq+3mXpkVM5csbibsdh/atl/ z9Q/99ij+1bL/n6h/wC+xXO/8I/pH/QKsP8AwHT/AAo/4R/SP+gVYf8AgOn+FYfWV2FzHRf2rZf8 /UP/AH2KP7Vsv+fqH/vsVzv/AAj+kf8AQKsP/AdP8KP+Ef0j/oFWH/gOn+FH1ldg5jov7Vsv+fqH /vsUf2rZf8/UP/fYrnf+Ef0j/oFWH/gOn+FH/CP6R/0CrD/wHT/Cj6yuwcx0X9q2X/P1D/32KP7V sv8An6h/77Fc7/wj+kf9Aqw/8B0/wo/4R/SP+gVYf+A6f4UfWV2DmOi/tWy/5+of++xU8NzDOCYp EcDglSDXLf8ACP6R/wBAqw/8B0/wrFbWtI8E63qlxOkdrbPBbAJBFje/77gAdyB39KuFZTdrApXP SKK8o8O/GG58QeMRYQaS7WbxOIYYypndxzklmVQMA8fqa7z7T4hu/wDU2NlYIf47mYzOP+AJgf8A j9bFG3Uc7FLeRl6qpI/Ksj+wbq651PWr6YHrFbEWyfgU+f8A8fNaNlp1rp9r9ntYgkRJJBJYsT1J JyT+NAHERa34hktNIh+0zyz3mnnUJJbaG3BXhAEAkZRtG4lj1ORjaKePEesS2t7qMl9FB9igtJjZ xJHIsrSIpZd/OQSSFKnr3IrsLrRNMvreC3u9OtJobcAQxyQqyxgDGFGOBjjiqyeGtO/tibUprWCa d2Ro2kiUmHaoUbTjI6ZoA5u41vXEjylxJL9s1aaxhWCGIPDHGZTkFyFLnYB8xxjsT1bPr2u/2dG7 SvF5AuDO9uLeWYBHAR5IwxG0DIcIc7hxiuyn0uwubR7Weyt5LeRzI8TRgqzE7ixHrnnPrzUMvh/S J4LeGXTLJ4rYEQo0ClYweoUY4FAF6GQTQpIrBldQwI6EGn1n6vqMmk2q3f2czW0bZuCp+aKPu4GP mx1I64yRnGDeR1kRXRgysMgg5BFADqKKKACiiigDE8Y4PhLUox/rJovJi/66OQqf+PFa26wZm/tv xFHAnNlpbiSZu0lxj5E/4ADuPuU9DW9QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAG L4t/e6E9mOt9LHaY9VkcK/5JuP4VtViaj/pfinSbUcrbLLev7EL5aA/XzHP/AAGtokAZJwBQA2WV IInlldUjRSzMxwFA6kmsKxifxFexapdoy2EJ3WEDjBc/893Hr/dB6DnqeGKf+EuuA3P9hRNlfS+c d/eIH/vs/wCyPm6OgAooooAKKKKACiiigAooooAKx9bYrA2K2Kxdd/1DfSgCp4N/5E/Sv+vda2JJ EijZ5HVEUZZmOAB7msfwb/yJ2lf9e61oalplpq9jJZ38Ilt5MblyRyDkEEcgggHivNl8TEZz+LtM A82NpprUOqPdxxnyELHAO84BGSMlc4zzVGXxqqXaPHY3c9k9m10piiBfaHI38sBtIAI7nI47Vauv DVzd2jafLq00umyFRLFLGDIyA8xiQEHB6EkE4zzRa+GZYYmSbUDMfsLWKs0WGCbiVJ55IBAPTOM8 ZqvdAi/4TKOO7u0ksrloY5oYYHiUMZjIm5cDP+e9IvjS3nilENpeRSBZlRriIBPOiUlozhs5G09O ODg0+Hwo8NzG4vVMaSW8u3yeS0SbOu7oRjtx70svhTzYUj+2Y23V1cZ8rr5yyDHXt5nXvjtmj3QL Fh4ms5xbw3kn2W7lRWVZkMaykgH92x4b6Ak1s1gP4W+22qWeq30tzZRosYtY18qNgoA+fBLN06bs e1akVvdxvGPtMXkrIx2CHH7vGFUHdwQcHPfGMCpdugFuiorZJo7aNbmVZZgoDyKmwMe5C5OPpk1L Ugct4BcnQLMf7H9a6YfvdbPpBbjH1dv/ALD9a5jwD/yArT/c/rXT2XzX1+/pKsY+gRT/ADY16fYG XqKKKYytenEBrjNIOfFWs/8AXG3/AJy12d7/AKg1xej/API1az/1xt/5y1lX+Bilsb9YcHiCTVbq WDR7dHWCTZNNcSbAhB5wg+cn6hR71uVTu9Ksr6ZJri3UzR/clUlZF+jDBA9s1wq3UzOWn8R6jqOm XqxLDDPY3MFtIY5CN83nqDgg5EZX15+Yjsc221XV31eys5JrVHi1P7POY422zIbZpRwWyO478gHp kHXTw3pcaoqWoUIiIMOwyEcOueeSGGcnJ5PqcyyaPZS3HntE3m+etzvWRgfMVNgPB/u8EdCM561X NHsM5qHxJr09rbyrFpq/aLB75chztCbcqeeSdw57c9auWWq6jLcajdW0KXEAljZoZJ9jIpgib5CR t6kkg4HPWtiPRLCKKKNIMJFbNaoN7cRHGV6/7I568VGfDmlsRvtFdchijszISFVQSpODgKoGR29z RzR7ASaPrNtrlmbm037VcxsGHRh1GRkHr1BI96v1XlsoJmUsrDZG0ahHZQFbGeAQOwweo7Yp0FpF byM8e/cyKh3SM3C5xwT15PPU981DsImrBh58b3oPINrBkf8AApa3qwYf+R5vf+vW3/8AQpK2w/xl R3OntPD+kRXkd/FplnHeJnbOkCq4yMHkDPQkfjWrUUH+qFS13FhRRRQAUUUUAFFFFACEAggjIPUV h6FnSr640JyfKiXz7In/AJ4E4Kf8Abj/AHSlbtY3iO3lW3g1O0RnutOfzgi9ZIyMSIPqvIH95VoA 2aKit7iK7tori3dZIZUDo69GUjII/CpaACsnW9RmhMWn6dtOpXeRFkZEKD70rD0XI47kgd+Lmp6h DpWny3lxuKRj7qjLOxOFVR3JJAA9TVPRNOmtxLfahtOpXmGmwciJR92JT/dXP4kk96ALem6dDpVh HaW+4omSWY5Z2JyzMe5JJJPqat0UUAFFFFABRRRQAUUUUAFFFFABRRSE4FACO4QZNYMniSW6nki0 WxkvvLYq85cRwqw6jeeWI/2QcdDiofEtzLcPa6VbSvFJfzeU0iHDJGAWcg9jtUgHsWFa1tbQ2VrF bW0SxQxKEREGAoHQCsatXk0W4Gb9v8S/9ArTP/Bi/wD8Zo+3eJf+gXpn/gxf/wCM1r1C15At8lmX /wBIeNpVTB5VSATnp1YfnWHt5iM77d4l/wCgXpn/AIMX/wDjNH27xL/0C9M/8GL/APxmteoby8gs LV7i5fZEmNzYJxk4HA9zR7eYzBtk8Sw6re376fpkklyI0Uf2g48uNAcL/qefmZzn/a9qj1WLxPqw jt5rHTkss5niXUHBnHZS3lcL6jHPTOMg9JNcw25iE0ioZXEaZ/iYgnA/I1JR7eYjHS88RxoqJpOl qqjAUai4AHp/qaG1/UrAb9V0hkgH3prOb7QEHqV2q2PoprSivIJrqe3jfMsG3zFwfl3DI578VNR7 ea3GSWt3DdwJNBIskcihkdTkMD0INT1yVki+H/Ej6fAojsbyNrmCMDCxuGAkUDsDuVsepaurRtyg 11xkpK6AdRRRVAFFFFABRRRQAVk6zGXhYCtaoZ4RKpBoA84sPE+q+HtKttPOjW84tkEYkF6y7sd8 eXx+dSf8LF1P/oXof/A8/wDxququNCjlYkqKr/8ACNRf3B+VZOjB9AOd/wCFi6n/ANC9D/4Hn/41 R/wsXU/+heh/8Dz/APGq6L/hGov7g/Kj/hGov7g/Kj2MOwHO/wDCxdT/AOheh/8AA8//ABqj/hYu p/8AQvQ/+B5/+NV0X/CNRf3B+VH/AAjUX9wflR7GHYDnf+Fi6n/0L0P/AIHn/wCNUf8ACxdT/wCh eh/8Dz/8arov+Eai/uD8qP8AhGov7g/Kj2MOwHO/8LF1P/oXof8AwPP/AMaqaDx7qs7YXQLcfW/P /wAarc/4RqL+4PyqWHw/HG2Qgo9jDsBV8G2MtjpFtDPt8xEAbacjPsa39N5+1nubl/0wP6U+1tRC oAFM03g3a91uXz+OD/WtOoupdooopjILpd0JFef6pbanp2rXN5ptxGnnoiOkkO/7pbBByP7xr0Vl 3DFUrjTkmPIpNJqzA81Ot+Jwcedaf+Ax/wDiqT+3PE//AD2tP/AY/wDxVegHQos/dFH9hRf3RUey h2FZHn/9ueJ/+e1p/wCAx/8AiqP7c8T/APPa0/8AAY//ABVegf2FF/dFH9hRf3RR7KHYLI8+/t7x Lu2/aLPd6fZj/wDFUv8Abnif/ntaf+Ax/wDiq2ptA1H/AISEMkEYUsXQFxgopAP8x+ddN/YUX90V MYRd7omOt9Dz/wDtzxP/AM9rT/wGP/xVH9ueJ/8Antaf+Ax/+Kr0D+wov7oo/sKL+6Kr2UOxVkcC mteJmbBntB/27H/4qtvw9ZXkmpzX9/Mkk0qJH8kewAKWI4yefmNdIuhxA/dFXLexWHoKpQindILF qIYjAp9IBgUtUMKKKa7bVyaAAsF61kX/AIq0vT5zbyXPmXA5MECNLIPqqAkflWVql9c6zqkmmWcz wWsAH2ueM4ckjIiQ9iQcluoBGOTkWLOxttOgENnAkMY5woxk+p9T7msKlZQdkS5WHHxgp+5pOqsP X7Pt/mQaT/hLz/0B9V/78r/8VU9RzXMNvt8+aOPdkLvYDOAScZ9gT9Aay+sS7C5mM/4S8/8AQH1X /vyv/wAVR/wl5/6A+q/9+V/+KqZHWRFdGDKwyGByCPWmzTR28LyzSJHGg3M7sAFHqSelH1iXYOZm RpGvz6VLc2qaPqbaeW8y2/dLui3Elo8bvug8j2OOwzp/8Jef+gPqv/flf/iqnoo+sy7BzGNea/Nf a1ZyzaPqf2K0BlVfKXLzHhSRu6KNx+rA9q0v+EvP/QH1X/vyv/xVT1Cbu3Fs9wZ4hAm7dJvG1dpI bJ6DBBB+lH1iXYOZif8ACXn/AKA+q/8Aflf/AIqj/hLz/wBAfVf+/K//ABVTMypjcwGTgZPU0tH1 mXYOYg/4S8/9AfVf+/K//FU4eMYU5n07VIV7sbRnx/3xmnLNG0zxLIhkQBmQMMqDnBI7ZwfyNPo+ sy7BzF3Tdd0/VlY2V1FMU4dVPzIfRl6g/WtAHPSuU1DSLe/ZZTuhu4x+6uoTtkj+h7j2OQe4q34e 1ie4aax1HYL61IEhQYWVTnbIo7A4PHYgjnGTvTqqenUpO50NFIDkUtajCiiigApknCGn01hlSKAO NvphF4y0d5PuM8sIJ7MyEj/0HH411Nct4r0xrqA7GZHVg8br1R1OVYe4IBpmkeOrTylt9fdLC9QY aRwRDL/tK3Rc/wB1iCOnPWuWvBt8yAseNoLm4sbFYhutRdA3am3ecGPY2N0aEMy79uQD7ngGsCPT bsWShxfmA2V0qvHZsrRq08RVRGWLbcAkITuKjGB0rrP+Eu8Pf9B7Sv8AwMj/AMaP+Eu8Pf8AQe0r /wADI/8AGsU5JWsI4ySzujZ2iNZxxaXHdSmQLp88kMhMabH+z7g6rneMcru575rZuLe5k8BDS5I7 6a5aBWyYHRtvmjA6thguONxOBk1tf8Jd4e/6D2lf+Bkf+NH/AAl3h7/oPaV/4GR/40232A5u70CK 11fZFpj/AGCHUbeZFWFnVcxsHZRg/wAW3JHfk1BZeFIpv7MN3p87eZa3Zut4f5n3p5Yf6AttB6Y4 6V1f/CXeHv8AoPaV/wCBkf8AjR/wl3h7/oPaV/4GR/40c0gKHg6C8jEsl9FOkslpZ7mlUgs4iG7r 3B6+9dNWR/wl3h7/AKD2lf8AgZH/AI1T1Hx9oNjbu8N7HfyAEiKzYSk49SPlX6kipalJ7AR69KG8 XaREh+eKCeR/YMUA/PB/75rq7U5hGa8p0XxXpU+pT6lqur2gurgjID/LGgztQewyee5JPevV7Uq1 ujIwZWAIIOQRXdTjyxSGTUUUVYBRRRQAUUUUAFFFFACUUtFACUUtFACUUtFACUUtFACUUtFABVG0 +TUr+P8AvMkw+hUL/NDV6qN1/o+pW1x/BIDA59CeVP5gj/gVJiZeooopjCiiigAooooAKKKKAKU/ GsWZ9YpV/wDQD/SrtUrzjUdPPq7r/wCOE/0q7SXUSCiiimMKKKKACiiigAqpfyFISR6Vbqrex+ZC RQByPhmQOupKf9at9IZPXnBX/wAdK1tVyOpC80LWG1GyTzFcBbiAnAlUdCD2Yc4PfoexGxpnibS9 VwkFysc/e3m+SQf8BPX6jI964a1NqTfQiSNavO573zbu1lbUpn1ETXhmtjLkQFYpguF/hwMY/vZz zXolJgAkgDJ61nGViTirbUZRrln5l88pYwIIY7kq6bo1zuhIw6kktvHI59DWSmom58KqYtSnvprj R5XvkkmLiJgq7SR/CckjtkZPOM16XtG7dgZxjNQWFlDp1hBaW4IigjWNMnJwowMn6Cq512Hc5C61 mVPFKeRclT9u+ztFLdnkbCAPJAwFLYIcnJJHqKrf2nMnh/7TZ6tcTX7wRm/R5SVt2aRBIScHyioL jAHABOPlrv8AAznApcDnjrS512C5wcN/IUiju9WWLSmvShuIb55NuIsiMzsq5BbnIJ5+XPanxXMT fDW+txc75nivJFL/AH3UTOC5H1I/Ou42Lt27Rt9McUtHP5Bc4bVbf7PfS2k99dvawXNjPvluWyhd 3VjuzwPlBx0B6Yp1nb3N7d2Hm6pqAW7nvElVLgqNqO2wLj7uMDkcnp04rt6KOcLnK+DrmW8ne4uH Mk0mm2TO56sf3uSa6qikZgilmICjkkngVMnd3ELWMsoHjhRH1SxAlx7v8n8n/Oq+peMbG3LQacRq F50CQtlEP+2/QfTk+1P8LadOJZLq7cy3Vw++WTGMnsAOygcAeldFCm78zKijuIjmMGpKZENqAU+u ssKKKKACiiigCpeWizoQRXLaj4ZWZiQtdpTTGrdRQB5s3g8Z+4Pypv8Awh4/uD8q9I8hPSj7PH6U Aeb/APCHj+4Pyo/4Q8f3B+VekfZ4/Sj7PH6UAeb/APCHj+4Pyo/4Q8f3B+VekfZ4/Sj7PH6UAebj weP7g/KtCx8KrGwJX9K7jyE9KcIlHQUAeWa18F7TU9atLyxlW1gaUG8hxwy9SU9GPTHTnPbB7oQa /poAhnttVgXok48iYD/fUFG+m1frW30paAMVfFNnCwj1SOfSpCcYvE2oT7SAlD9N2fathHWRA6MG VhkEHIIrMGvWU/iGXQikjTrB5rFlHlt0ymc8sAykjHRhVGfTdB07/SbbUE0fdIU3W9ysUbODggoc xls5z8uaAOjorFl8TadYX32C8uWSYSxwh5doEjOpYYx7DngdRV8apYNLcRC9tjJbLunQSrmIerDP yj60AW6Kovrmlx436lZLubaMzoMnJGOvXKkfUH0qV9Sso70Wb3lut0y7hCZVDkeu3OcUAWaKyrXx No91pyXyajapbPIYlkklVQXBIxyevH5VqUALRRRQAUUUUAFFFFABRRRQAUUUUAFRXNul1bPDJna4 xkdQexHuDzUtFAFSxuXlVobjAuYcCQDo3ow9j/iO1W6q3lo0xSaBhHcx/ccjgjureoP/ANeltLwX IZHUxTx8SRMeV9/cHsaS7C8izRRRTGFFFFABRRRQBSv+LrTj6XB/9FvV2qWo/wCtsT/08j/0Fqu0 kJBRRRTGFFFFABRRRQAUjLuGDS0UAY2paUtyp+UVx+p+D4rjIkhR19GUEV6QQD1qNoEbqKAPJf8A hCEThIyg9FYgfpSf8IX7Sf8Afbf416ubKM9hVXUHstLs3ubtgka4HAyzE8BVA5JJ4AHJosB4/wCI dDOhaPLfi1muFjI3BZSNoPc89Pp61h+ENPv/ABTdzXJUxWUHylULYdj0GSc8Dn8q9qs9Cl1Wdb/W YhGinNtYEgrF6NJ2aT9F7ZPNaGm+HNO0e0+zafbJBDvZ9i9Mk5P+e3TpSsB5p/whftJ/323+NH/C F+0n/fbf416t9hi9BR9hi9BRYDx+Pw5BJeNbAuJFJGPMbkj8atf8IX7Sf99t/jXav4VtrfW4biWa VhPK7DHy7X+8o+mA36V0P2GL0FTG/UmN+p5T/wAIX7Sf99t/jR/whftJ/wB9t/jXq32GL0FH2GL0 FVYo8p/4Qv2k/wC+2/xp6eBonYGSASY/v/N/OvVPsMXoKUWcY7CnYDjNK8LJBtwgAHQAV1tlZLbo ABVtYlXoKdQAUtFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAcRB4b1mKW01lppGv vt5uprH91hVk+R139yseP4iCUGO1WPEGn6jfSotnpssEJjuYyYBb7yzMMFi+QqOAWJALdM4PB6+i gDhLPQtUj+xTzWDlopbJnQyRlsJCyOfvY4Jz15HTNULfwnqw02a0kgvnuILO7jWR5LZYZXkVgNpV d7biQTvIwRzmvSqKAON1HwoZU1VLfToSkmhrZ2wGwDzMykqPTlkOenvxVe90rWptZSU2c5SO/t5/ 3RgEbxqqAszE+Yz/AHhjIGB34z3VFAHnbeHdVha1c2l4UhS7gMdsbZiTJLvDYlyu1l4J4YY5GK7f RrNtP0Sxs33bre3jiO595yqgctgZ6dcDPpTNR0n7ayywXl1Z3Kfdkgk+X/gSHKt+Iz6EVR/tq80f 5fEEKCAcDULcHyf+2i8mP68r/tCgDeopsciSxrJGyujDKspyCPUGnUAFFFFABRRRQAUUUUAFFFFA BRRRQAVWurNLkq4YxTp9yVeq+3uPY1ZooApQ3rpKtvfKscx4Rx9yX6eh9j+tXajmhjuImimRXRuq sMiqf+k6d033VqPxlj/+KH6/WlsLY0KKjgnjuYllhdXRuhU1JTGFFFFAFLUP9dYj1uR/6A1XapXv N7py+kzN+Ubj+tXaSEgooopjCiiigAoorO17UjpOh3V5Gu+VExCn9+RjtRfxYgfjQBbt7u3u1dra eKZY3MbmNwwVhwVOOhHcVNXA6BBN4cmvtL1bbp1vdWH2gTxXO4740CTSbtowxBRunUE03UddeHxV GYL1kWK/gt3SW9IJjZVBIgAwVO7PmMc5PHagDu4bmC5UNBNHKpGQUcMCM4zx7g1LXlEc02nWcl3Z TSJeHSv3YMzABftLCRgvI+VTuzg464rRtbi9vWt7SHV2+xzalHEJLO/e5YDyJWdPOZFzkqp4ztJ7 cUAejVjwaW7agdU1iWN5osi3jU/urZehIzjLnuxHfAwM5521mura7tNQa/vpS+s3dq0LSlkMK+ft UJ3IKAg9e2ccVz8+qPqOk6jA988kFxpRuSP7QaZ96upJbAAjba3zIuQBQB61RXnQ1S+fxO0cWoxK yX0MNvE9/ITJbEJkiEIRIGUsfMLcHuApr0WgAooooAr31sbq0eNDtkGGjb+6wOQfzFLZ3Iu7WOYA qWHzKeqsOCPwORU9UE/0PVGj6RXWXT2kA+YfiOfwNLqIv0UUUxhRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFIRkYNLUcsojGTQBjSaNcaTI1x4 eKIhO6TT5DiGT1KH/lm30+U9x3q7pes2+qCREDw3UOBNbTDbLEfcenoRkHsTWPZ+INZ1Kziu7TR7 cwTLujL3u1ivbI2cGqupwazqZjlbR4ILuH/U3UOobZI/ofL5B7qcg9xUe0h3A7KiuVsr/wAVx2wS 90yxmmXjzI7soHHrt2nB/Gp/7S8Q/wDQGtf/AAP/APsKPaw7gdHRXOf2l4h/6A1r/wCB/wD9hR/a XiH/AKA1r/4H/wD2FHtYdwOjornP7S8Q/wDQGtf/AAP/APsKP7S8Q/8AQGtf/A//AOwo9rDuB0dF c5/aXiH/AKA1r/4H/wD2FKNT8Q/9Aa1/8D//ALCj2sO4HRUVnaJqy6xpVteiMx+fGHKE52n0z3rR qwCiiigAoprNtGa52/8AEd7Hq81jp+npcmGJJJHe48vG8sAANpz900m0ldga89iRK1xZuIZzy3GU k/3h/Uc/yp1tfCWTyJkMNyBkxsc5Hqp7j/JxWD/buvf9Aa2/8Dv/ALCobnU9Zu4wkuiW/ByrC/wy n1B2cGs/aQ6Mm66HX0VycOteII4VWTS7eVx1b7Zt/wDZP8PpT/7d17/oDW3/AIHf/YU/aw7jujcu Pm1izX0jlf8ALaP/AGartcgdV1xrxLj+yLfckbRhftvqQc52f7Iqb+3de/6A1t/4Hf8A2FCqQ7iT R1NFct/buvf9Aa2/8Dv/ALCj+3de/wCgNbf+B3/2FHtYdx3R1NFct/buu/8AQGtv/A7/AOwq3o2v z397dWd7Zraz26RvhZvMDK+7HOBz8h/SqU4t2TC5vUUgORRVDFpNoznAzWVc+JtLtpjAlyLm5/59 7RTNJ+Kpkj6nAquYtX1vi4L6RYnrHG4NzIPQsMrGP90k/wC0KAJb7WpHu20/Rokur5eJXY/ubbPe Qjv6IOT7DmtW3jaKBEkZWcD5mVdoJ74HYVHZWNtptqltZQJDCnREGPqfcnue9WKACk2gdAKWigBN q7gcDIGM4paKKACiiigAqtqFu1xaMIsCZCJIiezDkf4fQmrNFAENrcLd20c6ZCuucHqPY+4qaqNr /o2o3Ft0ST9/H+Jw4/PB/wCBVepISCiiimMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACsrV5jHCxFatYuu/6hvpQBU8Hc+ENL/691rarF8G/wDInaV/ 17rWrdi4NpMLNo1uSh8oyglA2OMgc4zXmy+JiJaK4LUrPV20u6W7j1OTWDHhJkcyW+3I8wRrHtwS m4DcAx6Ak1FY6K109tEIpX019RRmijsZLWJQIJQx2MxbaSVByACfXJquRW3A75rmJLqO2aRRNIjO id2VSAx/Asv51JXm9zokkMbhNNnLR2mr21qRAzFMuDCoOMgFd4Xtg4HUVf1LSG0+6stNsY5Ft9Yh W2uPmJKlH3uxJ5yyNKCfXFHIu4Hc0VykFtqY1NW0FLu1svNzMNQfMTjPzeWhzID6cqvsa3v7Vj8r zPs95jyXmx9mfOFOCMY+8ey9T2qWgLtFIrblDAEZGeRg0tSBzfgOYt4esl9IwK6+uK8A/wDICtP9 z+tdpXqDFooooAgum2wk1xumyGTxXrBPaC3H6y12F7/qDXF6P/yNWs/9cbf+ctZV/gYpbG/RRXNa pBqb38rX4uZ9Kz8kenvsYDv5g4dv+ANz/drhSuZnS1HcXEVrA807rHEgyzN0ArhbKxvP7ZLuJVuh czMzLYybmgw2xTKX2lNpXCgZBA4yCajn8PNFocUcWnzM02i5uVMbMXmUxFdwP8fL4HXt2quRX3HY 9Cori5dKWG31jVoreWOa2uUuLYurL+5jjiYqqnGAQGU+/wBKfDaTtZw3FvBqQ1a7DXJkhk2JGHYs qvuyh2jAxhiMdKOXzCx2NFZlneXVrZLHqqmW8jjDytawOY2yxAC8ckY5H44ANX4pxM0oCSL5b7Dv QqCcA5Geo56j39KhoRJXNPZreeNbxXuLuJRawZWCdot3zSdSpB/WulrnhJ5PjW7ba75tYOEGSPmk rah8Y47nRReFNNaMF21Bz/t6lct/N6f/AMIhoZ/1unRTj0uC0o/Jyasw6rbLGBIJ4/8AfgcD88Yq ePU7GY4jvIGb+6JBn8q7bou6JLa0t7OIRWsEUEY6JGgUD8BU1ICCMg5FLTGFFFFABRRRQAUUUUAZ Fz4lsbLWJ7C6LxeRai6eZkbywuSMZxjPH9OtIfFmjra+e90yL5wg2PBIsgkKlguwruyQMjjntVLx B4evNTv5prdrfZJaxoPMYjEkcolXIAOVJ4Pp6GmJoGoXesw6reJawyi7jleGOVnAjSGVBhioy26Q noOO/FAGhYeK9H1ObyrO8Ej+W0g/duAQuNwBIwSMjK9R3FSP4l0uOa3ja5Ia4SN0PlOVAc4Tc2ML uPA3YzWdYeHbuyk05w1uTaTXkrAMcN5zsy44/wBoZ/rVLXPDut6vNI7NbHeIHRBeypHG6EM67FXE mSOGbpnpxyAXYPFVlc61DbXMEkMy/bNsvzFFWGQIxZsYGevPTAz1Gbi+LtFazlujfBIYigdpI3Qj ecIcEA7Seh6H1rFvPB17dRzRGa3VLiPUoXYO2UW5kV0YDHJG0Ajjr1OOUt/CV7IwmuIreKVZrU/N f3F0WWKUSN80nQccKB9TzwAbkXizR5byO1S7PnSOsYUxOMMyhlViRhSQRgHBNNufFmlwRXrJK8r2 kUkjIsT/ADhDhthxhsHAOM4zzVabw9cyC82vCDPq8F8vJ+4nlZB4+9+7bHbkc1kjwjrE1yJLqWB2 Nvc27ytdyvu81cKyxldsYGBlV9epxyAdAnivSj9mWS4MUlxGkgV4nGwOcLvOMJk8DdjPatmuFl8G 6hNcyNNHA6XkcCzj+0LhEiKKFYbE2iQEKCM7eSe1d1QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVja4uYGx6Vs1Sv7fzoyKAOX8Ja/pEHhTTYptUsY5EgCs j3CAqR1BGeK2P+Ek0T/oMad/4FJ/jXN6h4UinlZvJTJOfuiqH/CFx/8APFP++a53h03e4HZ/8JJo n/QY07/wKT/Gj/hJNE/6DGnf+BSf41xn/CFx/wDPFP8AvmuD8bajbaHdvpVlCv2xQPNkZMCPIBAH qcEc9v5L6su4Ht//AAkmif8AQY07/wACk/xqA6x4cN8t42p6YbkJ5ayG5TIXOSBzxXGWXgkJYW6y xq0gjUMSvJOOai1TwSW06VreBTPGPMjAX7zLyB+OMfjR9XXcDv8A/hJNE/6DGnf+BSf40f8ACSaJ /wBBjTv/AAKT/GuGtfClte2kNzBGjRTIsiHaOQRkVN/whcf/ADxT/vmj6su4HZ/8JJon/QY07/wK T/Gj/hJNF/6DGnf+BSf41xn/AAhcf/PFP++as2nhCKNwTCn/AHyKPqy7gaXgDDeH7JgcqYwQR3Fd pWZpdkLaJVAwAMACtSukAooooArXozAa4Oy1Cz0/xXq4vLu3ty8NuV82RU3cydMmvQZk3xkVyes+ H0vXLPGrH1K5qZx5o2E1cd/wkGj/APQVsP8AwJT/ABo/4SHR/wDoK2H/AIEp/jXPN4MjLf6lP++R Sf8ACFx/88U/75rD6su4uU6L/hIdH/6Cth/4Ep/jSf8ACQ6P/wBBaw/8CU/xrjL7wwJLtNNs40+0 Ou+Vwo/cR9N31PQD6nsavxeB4YYljSBAqjA+Wj6su4cpv3Wq6BfQGC61HTpYm6o1wmD9eeR7VN/w kGj/APQVsP8AwJT/ABrykyWqfEY6Kwj8gqIBwMeb1/PJ2/Wu0/4QuP8A54p/3zR9WXcOU6L/AISH R/8AoK2H/gSn+NH/AAkOj/8AQVsP/AlP8a53/hC4/wDnin/fNH/CFx/88U/75o+rLuHKdF/wkGj/ APQVsP8AwJT/ABrM066t77xney2k8U8YtoAWicMM5k7iqUfgyMOD5Kf98iun0XRVsgAiKvrgYq4U VB3uCjY6OD/VClkhjmGJY0cejKDSoNqgU6tiikdHsc5S2SI+sWYz/wCO4o/s5k/1N7dx/Vw//oYN XaKVkKyKPk6jH9y6glHpJCQfzB/pR9ov4/8AWWUcg9YZsn8mA/nV6iiwWKP9phP9daXcX1iL/wDo Gacur2DNtN3EjH+F22H8jirlNZVdcMoYHsRmjUNQR0kXcjKw9Qc06qb6TYO242cAb+8qBT+Y5pP7 KgX/AFcl1H/u3D4/InFGoal2iqX2CZfuajdr7Hy2/mtH2S8HTUXP+9En9BRcLl2iqX2O7PXUZB/u xID+oNJ/ZaSf8fNxc3Hs8m0H6hcA/lRdgMuJRqFwtrAd0cbh53HQYOQn1JAz6Dr1FaNMjiSGNY4k VEXgKowBT6EAUUUUxhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUhAPWlooAjMKHqKT7PH/dqWsnV9Ungmj0/TI0l1Kddyh/uQpnBkf2HYdWPAxyQAJq mo22nPHbxwvdX0wzDaxY3v7nsqjux4/HArKn8B2OvBrjxRDHd3b4CrGzKluoOQiEYJ56seW9AMAb mlaRDpaSMHee6mO64uZcGSVvf0A7KOB2rQoAi+zx/wB2j7PH/dqWigDn/DsCWkuoaSw/485y0Q/6 YyfOn4Al0/4BW39nj/u1k6l/oHiXTb4cR3QaxmPufniJ+hDL9ZK26AIvs8f92gQIOgqWigBAoHSl oooAKKKKAEprRK3UU+igCL7PH/drO1m8TToY47eET31y3l20Gcb27knsoHJPYe5ANvUtRg0qxe6u S2xcAKoyzsThVUd2JwAPeqejadOs0mqaoFOo3C7dgOVto+oiU/qx7n2AAAH6RocemWzeY/n3czeZ czkYMr+uOwHQDsABV/7PH/dqWigDz68+Hfh6PxzZXD2khN2J52YzuD9oV0dSCD6GQ49q7z7PH/dr J8TfuILDUB1sr2KQn0RyYnP0CyE/hW3QBF9nj/u0fZ4/7tS0UARfZ4/SnLGq9BT6KACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooARmCKWYgKBkk9qxfC0Zn09tXmB+06oRctnqsZH7p PbamOPUse9ad/A1zp1zAhAaWJkBPqQRVTw3Ot14Z0yZBgPaxnB6g7RkH3B4oA06KKKACiiigDO1+ wfU9EubeAhbjaJIGP8MqkMh/BgKm0u/TVdKtb6IFVnjWTaeqkjkH3B4/CrdYeif6BquqaUeEWT7Z bj/pnKSWH4SCT6BhQBuUUUUAFFFFABRTWdUxuYLk4GTjJ9KdQAUyWVIInlldUjRSzMxwFA6kmn1j axaHUr+zs7qWKPTmO54mfD3TjkR47qACxHfAHTOQCHTIn12+TWbtGW2jz/Z8DjGARgzMP7zDoOyn 1Y1v1H50Xn+R5iebt3+XuG7bnGcemakoAKKKKAKOuWP9paFf2Q4NxbvGD6EqQD+dO0i9/tPRbG+/ 5+beOb/vpQf61crF8IfL4Xso+0IaEfRHZR+goA2qKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACsHTG/sfWZ9Jk4guWe6smPQ5O6WP6hiWHs3+ya3qo6tpiarZeSZGhlRh JBOg+aGQdGH9R3BIPBoAvUVl6Nqr3nmWl8iw6lbYE8Q+6wPSRPVGxx6cg8g1qUAFFFcbc69f/wDC SxR29xcGylvjZH91EsSkRtkKSfMZwwznG3qKAOyrK1KznGsabqFpHvaJmgnUEDMLjk/gyofpu9a5 LRr7VW0aCBdYkgFvphvTPJHG5lbe42tkfcUKM4wfmHNSSa1r935tzDfJaKLuzthbmBWCedHEXyTy SpkJHuOcjoAd9RXKRXl9LoOoi5vlleyluoWMkKZuVVDtBAwARkE4HOOnNYt7fX1/pLSNexwW1rd6 fbizESgSbjA5bPUHL8AcYXp6AHotZ+v3n2Dw/f3WZR5UDsDFjeOOozxke/FaFFAHl32wXfm291qG ba21CxmRo9SecIGcqx807SRkD2U9KuDVLjaJYdVmfVWe8W/tftBKwIiSlSI84TawiAYAZzyTmvRA oAwAMdOlJhVJbAB7mgDze7W+tLO9nXWdTZrbRoNQUNcHBnJfJP8As4QfJ93npW74ivprTUI/7Kup J7rz5t9vvyFcWbsiY7A4VsepzW5omoyatYG9ZFSCZ2NtjOWizhWP+9jcPYitGgDhvCk1pN4qDWWr Takp0tWkeSbzdrlxkZ7Hple3oM13NIAF6ADvxS0AFFFFACVjeD/m8K2EnaZDOPo7Fx+jVP4imnh0 C7+xqzXUieTCFGcO/wAqn6AkE+gBq7Z2sdjZQWsIxFBGsaD2UYH8qAJqKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDM1jSP7RWOe2mNrqFvk29wBnbnqrD+JDgZH 4jBAINJ1f7eZLa5i+zajb48+3JzjPRlP8SHsfwOCCBlah40/s+TUjLYhbezuEtVnkuFRZZmCEDkf KoD5LHpjv2htvGf9pTW8Wn6fb3d80ssBMd2rRIURHJEoU5Uhx0Gc8EUAddVBtD0t7xrt9Os2uWYO ZTCu8sCCDnGcjA59hWJ/wnC/NIdPkFvBZG8u5DKP3AVpFZMfxMGjIGOvPTHMEPxCt3tLp2htTNAs T4hvVliCyPty8ij5Np5bg4HTNAHQS+HdHnSNZdKsXWN2dA0CkKzHLEcdz19atNY2rM5a2hJeRZWJ jHzOuNrH3G1cHtgelQ6RqDanpkV08SRl88RzLKhwSMq44IOMg8fQVdoAyL37DbanZW8+nW7R3jyh Zii/LMU5BGOrpvGc9sd6sSaFpU11Hcy6bZvPGqqkjQKWUL90A44x29KNb046rpU1vG4jn4kgk/55 yqdyN+DAfhkUuj6iNW0qC72GN3BWWM9Y5FOHQ+4YEfhQBeooooAKxvFEjvpiafCxWbUpVtFK9QrZ MhHuI1c/UCtmsSf/AEvxnax9UsbN52H+3K2xD+SS/nQBsRxpDEscahUQBVUdAB0FPoooAKKKKAOF i8Y6vJY6UZILaO41GF7pTFaz3CxxKEGCqZYli454Cj1PWVvFusSWt3eJZ21tDYWMV7cw3KuJTkOX QdNpAQ4JHccem/L4Z02Wzs7YRSxJZp5du0NxJG8akAFd6sGwQBkE9h6VjTeHdIi8RLbSxu63NvFF FaQSOqrFFuyZAGAZMso+bPPHOTQAy88W6lbrdSCC38o3/wBgtdsUsrlsbi7KvJAUH5QMkjqKbP4s 1ZNNjmNmLfbJKktzNYz+X8u0ofL4dFYMfmOQpU9a6OfQdPuLWWB4WCSz/aCUkZWEuc71YHKnjsRV c+FNLMMUYjuEMe/94l1Ksj78b97htzZwM5J6D0oA1Lab7RaxTAofMQNlG3LyM8HuPepajhhjt4I4 YUCRRqERV6KAMACpKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD IufDdrcw3aedPG9zdLeCVCu6KVQgUrkY/gHBBzk9qoXPhi7fUNOli1W93QtO8t0WQyBnVVACldgX A6Bcd+vNdNRQBhweEdOgtZ7b99JDcWYs5Vd87ky7Fs4zuJkYk/kBUE2mR2SrBd+INSW4uWRLeeR0 XaVOQoAQIScnIYEt+Ax0dQ3dpBf2sltdwpNBINro4yCKAK+k6VDo9kbeF3fdI8ru4UFmYkk4UADk 9ABV6ueFxdeFzsvpJLrSP4LpstJaj0l7sn+31H8X96t9HWRFdGDKwyGByCPWgB1YUX/En8UPEeLT VsyR+i3Cr8w/4EgDfVGPet2s/XNNbVNLkhhcR3KES28p/wCWcqnKn6ZHI7gkd6ANCiqWj6kuraXD dhDG7ArJEescinDofcMCPwq7QAVi6T++8R69P/zzkhtR9FiEn85jW1WL4d+aXWJO76jJn/gKon/s tAG1RRRQAUUVnazrCaRbIRDJdXUzeXb2sRG+ZvQZIAA6kngAE0ALq+qrpkKKkZuLyclLa2U4aVv6 KOpbsPwFM0fSmsFluLuQT6hdENcTAYBx0RR2RegH1J5JpukaTJbzSX+ous+pzrh3X7kSdRHHnoo9 erHk9gNWgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKAEIyMHkVgPYXXh12n0eJp9PJ3S6evWP1aHPT3Toe2DwegooArWGoW2p2iXNnKJYm4 yOCCOoIPIIPBB5FWaxr/AEeaK7fUtFdIb1sedE/EV0B2fHRvRxyO+RxVnStXh1RJFVXguYTtntpe JIW9x3B7EcHsaAKQ/wCJN4nK9LPVjkeiXKrz/wB9oufqh7tW7VHWdNGq6XLbBzFKcPDKOsUincjD 6MAaboupf2ppkU8iCK4BMU8Wf9XKpw6/gQceowaANCsXwxzbagfXUbn9JCP6VskgDJOKxvC3Om3T 9n1C8I/C4kH9KANqiis7V9XXTVjihiNzfXBK29spwXI6kn+FR3bt7kgEAXVdXj0xI0EbXF3Odlvb R/flb+ijqWPAFRaTpElvM9/qMi3GpzLteRR8kS9fLjB6KPzY8nsAuk6Q1nJJeX0oudSnAEs2MBV7 RoP4UHp1PU5NalABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFNZgoyaxLvX5HvHsdItTe3aY8z5tkUOem98HB9gC3tjmgDczRketYI0rX bn5rvWo7bP8Ayzs7YfL7bpN2frtH0pf+Edvf+hm1f/v3a/8AxmgDd3D1rM1XSEv3jurab7LqMIxD cqMkD+6w/iQ91P1GDg1V/wCEcvf+hm1f/v3a/wDxmj/hHL3/AKGbV/8Av3a//GaALOl6ybmZrG/j W21OJdzwg5V1zjfGf4l/UZwcV5BLZeIfD3xf0mbXbprqG5vR5VyihI5CwEedo4VsYBHXjuMGvTbz wZJfNC8/iLVmkgcSROEtgyN7EQg+xHccGpLjwjLdrGtz4g1OURyLKm+K0O11OVYfueCD3oAT4hac NW8BaxbdWFuZVA6kphwP/Ha5X4JaBc6f4el1W8mm/wBNOIIWc7VjB+9t6ZJz+A46117+GruRGR/E urMrDBBjtSCP+/NNh8LXFvCkMHiLVY4o1CIiRWgVVHAAAh4FAGhq+rppkUaRRm4vbg7La2U4Mjdy T2UdS3Ye+AY9G0prLfd38qXGqXAH2icDCj0RAfuoOw79Tkk1nJ4Nkjv5L0eItXNzIgjaQrbEhR2G YeB3wMZNWP8AhHL3/oZtX/792v8A8ZoA3dw9aNw9awv+Ecvf+hm1f/v3a/8Axmj/AIRy9/6GbV/+ /dr/APGaAN3I9aWsL/hH9RTmPxJqJP8A01ht2H/jsa/zpjTa/pQ33EMGqW4+81qpimUf9c2JDfgw PoDQB0FFU9O1O21S0S4tZA8bZGcYIIOCCDyCDwQeQauUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUh6UAYHinUJ7bTWjs3CXVw6W8LkZ2PIwRWx3wWz+Fa um6bbaTZLa2ceyMEscksWYnLMSeSSSSSa5nxis5tPNt1DTW8sdxGpOAzRuHAPsSuPxrpdJ1W11rT or2yk3wyD6FSOqkdiDwRQBcrMfxFpcdnFdvdqIJrZrpHKtgxLt3N07b19+a064NvB+s3GlRafM2n rFa6VcafEyyuxkL+WFdhs+UYj5Az170AdA3jPQkKBr7G9VYHynwFZioYnbwpIPzHjpzyK0P7Vsxf CzMw+0GXygm08vs8zGcY+7zWRq/h25vxr/kvAp1GxjtodxI2svmctgcD5x0z3qfVrLVLm/s7u1is 3NjdGSJJJmTzI2iZGyQh2sGY4wCCB2zwAXI9d06USFLlSI43lf5TwqMVY9OzKR+FVn8T6fAs8lxO ixJMkUZQO7yFo1kA2Bc5wc4GeBnjkDBj8La5a2RSFtPknuLS4tpmaV1WMySs6uvynd985Bx9ani8 M6nYXqX9t9knminR1hklZFZPsyQt8204YFcjg8emaANfSvElrqlhHcoDmb7Q0SR5cyJFIULDjv8A Kcf7XeorbxNJe6Mb210u5eY3T2qWzYVtyuVJc/wj5ST1x05qTw7p2oaTp1vaXItGG+4kmaJm4Z5S 6BQRyMMc5xjAxmqU2jaxb6Jc2uny24muNQmnc+e0X7l5GfAcIxVsEDOOOcHoaAJ4vEtzdBYrTSZZ bpZZYplMoWOIx7d37zGDncMDGTz0wcV4/Gsd3PZR2VvCTdW0VwoubpYWxIWAVRg7j8h6e3rUFzom ryadZ2NvpulwWEZf7RZx6jKom6bcyCHJBJcsMc8ZJ5Bdq/h6/wBUs5rUado0SXdskDSK532u0n7h 8sbwAQV+7g0AdbRVQNfiQDyrby/PxnzG3eVt6/d+9u4x0xznPFTWxnNupu1iSbncImLKOexIB6e1 AEtFFFAHNanEui+I7O+twEi1KQ290g6NIELJJ9cIyn1yvpXRRvvQGuS8RajHqXiOw022YOLCU3Ny w6K+wqifXDliO2F9a6i0z5IzQBYooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigDL1Wy+0RMMVwc1rqegahJd6POYHc5kjZd0Uv8AvL6+4IPvXpzKGGDVG60y OcHKigDkLf4lXUI26lojlgOXtJgwb/gL7cfmasf8LSse+jax/wB8wf8Ax2r8/hqNyfkFVj4Vj/uU AQ/8LTsP+gNrH/fEH/x2j/hadh/0BtY/75g/+O1L/wAIrH/co/4RWP8AuUARf8LTsP8AoDax/wB8 wf8Ax2j/AIWnYf8AQG1j/vmD/wCO1L/wisf9yj/hFY/7lAEX/C07D/oDax/3zB/8do/4WnYf9AbW P++YP/jtS/8ACKx/3KP+EVj/ALlAEX/C07D/AKA2sf8AfMH/AMdo/wCFp2H/AEBtY/75g/8AjtS/ 8IrH/co/4RWP+5QBF/wtOw/6A2sf98wf/HaP+FpWH/QG1j/viD/47Uv/AAisf9yj/hFY/wC5QBC3 xQtmH7nRNULdvM8lR+jms668WeIdcBhtYotLgbhmjYyzEezEAL+AJ9DW3H4XjB+4K07TQ44cfKKA Mfw3oS2UYCqeTuJJyWJ5JJPJJ9TXYRLsQCmxQLEMAVLQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAJijA9KWigBNo9KNo9KWigBNo9KNo9KWigB No9KNo9KWigBNo9KNo9KWigBNo9KNo9KWigBMD0paKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP//Z --Apple-Mail-90--992245976 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit There is the question I had brought up in an earlier e-mail [1] as to whether the alternate relation relates a representation and a resource or two representations. I think that the A:alternate relation is less ambiguous at present and so preferable. Henry Story http://bblfish.net/blog/ [1] http://www.imc.org/atom-syntax/mail-archive/msg13897.html --Apple-Mail-90--992245976-- From owner-atom-syntax@mail.imc.org Mon Apr 4 05:41:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11281 for ; Mon, 4 Apr 2005 05:41:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j349YPHp052287; Mon, 4 Apr 2005 02:34:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j349YPYb052286; Mon, 4 Apr 2005 02:34:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j349YOpL052268 for ; Mon, 4 Apr 2005 02:34:25 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1DINyR-00065g-00; Mon, 04 Apr 2005 10:34:23 +0100 Date: Mon, 4 Apr 2005 10:34:23 +0100 From: James Aylett To: atom-syntax@imc.org Subject: Re: Why is alternate link a MUST? Message-ID: <20050404093423.GA22458@tartarus.org> Mail-Followup-To: James Aylett , atom-syntax@imc.org References: <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> <42506E8C.8030409@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, Apr 03, 2005 at 04:13:55PM -0700, Tim Bray wrote: > I think is a SHOULD, to address auto-subscriptions, > one of the current #1 RSS pain points, perceived by users as a failure > to interoperate. -Tim +1 James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon Apr 4 08:17:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24928 for ; Mon, 4 Apr 2005 08:17:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34C4SM5005001; Mon, 4 Apr 2005 05:04:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34C4SYp005000; Mon, 4 Apr 2005 05:04:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id j34C4QR7004943 for ; Mon, 4 Apr 2005 05:04:26 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 40453 messnum 11065189 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 4 Apr 2005 12:04:20 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail11.svc.cra.dublin.eircom.net (qp 40453) with SMTP; 4 Apr 2005 12:04:20 -0000 Message-ID: <42512D42.8080101@dehora.net> Date: Mon, 04 Apr 2005 13:04:18 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Why is alternate link a MUST? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Eric Scheid wrote: > On 4/4/05 9:04 AM, "Bill de hÓra" wrote: > > >>Thus: I'm -1 to downgrading @alternate unless @self is lifted to MUST or >>atom:id is lifted to MUST. If either are lifted to must I'm 0 on >>downgrading @alternate. At that stage @alternate doesn't matter a whole lot. > > > -1: the reasons against @self MUST are similar to the reasons against > @alternate MUST. I don't understand. How are these alike? cheers Bill From owner-atom-syntax@mail.imc.org Mon Apr 4 08:35:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25988 for ; Mon, 4 Apr 2005 08:35:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34CQ4Ft012893; Mon, 4 Apr 2005 05:26:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34CQ4Lx012892; Mon, 4 Apr 2005 05:26:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j34CQ2cP012848 for ; Mon, 4 Apr 2005 05:26:03 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 45097 messnum 5761935 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 4 Apr 2005 12:25:57 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail12.svc.cra.dublin.eircom.net (qp 45097) with SMTP; 4 Apr 2005 12:25:57 -0000 Message-ID: <42513252.4090000@dehora.net> Date: Mon, 04 Apr 2005 13:25:54 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Why is alternate link a MUST? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > On 4/4/05 1:32 PM, "Paul Hoffman" wrote: > > >>Not to pick on Eric; others have said things along the lines of: > > > no offence taken. > > >>This isn't a negotiating game. We have to have technical reasons for >>our assigning requirements levels. > > > I can't think of any MUST reasons for link[@rel='self'] or > link[@rel='alternate']. Then let me try and help you with that. I can think of long nights tracking down data because I didn't have way to hand systems an identifier. In the Atom 06 format there are 3 things potentially acting as identifiers for the source of an Atom feed. The one that going by the commonsense name least likely to be considered a meaningful identifier is mandatory. Sorry to offend anyone in this WG, but that's absurd. Never mind that we're creating an arbitrary distinction between feed ids and entry ids. I have very strong opinions on this: too many identifiers cause problems when it comes to system and data management -worst scenario in terms of cost are too many unreliable identifiers. For a pure client/server newsreader case I can see how this might not bite so much. For anyone passing Atom along a processing chain or heaven forbid, something like a SEDA system, not having assured easy to find identifiers is a cost. Being able to rely on the presence of an (ideally, single) identifier is a management win and an interop win. It is one of the reasons Web based systems are easy to run. Not having such a thing for Atom feeds ensures people will have to invent it especially for non-HTTP scenarios. The upfront cost of mandating either self or id is so small versus the benefit of being able to shout out something's name when something goes awry I can't believe we're even having this discussion. Anyway I've made my position clear at this point. Please make id or self mandatory. [Please don't argue on the basis that URL links aren't identifiers or names and shouldn't be treated as such; it's de jure Web architecture that they are.] cheers Bill From owner-atom-syntax@mail.imc.org Mon Apr 4 09:12:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03592 for ; Mon, 4 Apr 2005 09:12:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34D2esa024150; Mon, 4 Apr 2005 06:02:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34D2eqZ024149; Mon, 4 Apr 2005 06:02:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34D2drH024143 for ; Mon, 4 Apr 2005 06:02:39 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 4 Apr 2005 19:02:38 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 04 Apr 2005 23:02:36 +1000 Subject: Re: Why is alternate link a MUST? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <42513252.4090000@dehora.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j34D2erH024144 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/4/05 10:25 PM, "Bill de hÓra" wrote: > Anyway I've made my position clear at this point. Please make id or self > mandatory. atom:id then, since atom:link[@rel='self'] could change at any point in time, and mutability is not a good attribute of an identifier. e. From owner-atom-syntax@mail.imc.org Mon Apr 4 09:13:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03694 for ; Mon, 4 Apr 2005 09:13:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34CxQhl023876; Mon, 4 Apr 2005 05:59:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34CxQjw023875; Mon, 4 Apr 2005 05:59:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34CxOvx023864 for ; Mon, 4 Apr 2005 05:59:25 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 4 Apr 2005 18:58:19 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 04 Apr 2005 22:58:17 +1000 Subject: Re: Why is alternate link a MUST? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <42512D42.8080101@dehora.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j34CxQvx023870 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/4/05 10:04 PM, "Bill de hÓra" wrote: >> -1: the reasons against @self MUST are similar to the reasons against >> @alternate MUST. > > I don't understand. How are these alike? one reason against @rel='self' is that the feed may not be retrievable at all (being delivered some other way) one reason against @rel='alternate' is that there may not be any web retrievable resource. e. From owner-atom-syntax@mail.imc.org Mon Apr 4 09:44:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07282 for ; Mon, 4 Apr 2005 09:44:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j341oM0l014492; Sun, 3 Apr 2005 18:50:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j341oMfu014490; Sun, 3 Apr 2005 18:50:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j341oLQJ014478 for ; Sun, 3 Apr 2005 18:50:21 -0700 (PDT) (envelope-from eliast@gmail.com) Received: by rproxy.gmail.com with SMTP id f1so1635988rne for ; Sun, 03 Apr 2005 18:50:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=YMPY1e1DFVtmb/iLKf9TzemCkmTTNvEme/09LMcj5wppIXZkSIlnA2DgsilPLkF47mW0SiEnLjkuZ6TTOViHE59iGqhqHbFOuikuja4DBT7K70x89E0nrEruo8BBD49IWzAeSiWtXn1jh3SmIoYRib4xeunKK7UXkAeWvB/6BLc= Received: by 10.38.72.79 with SMTP id u79mr4810450rna; Sun, 03 Apr 2005 18:50:20 -0700 (PDT) Received: by 10.38.12.62 with HTTP; Sun, 3 Apr 2005 18:50:20 -0700 (PDT) Message-ID: <905f7c9105040318506504f692@mail.gmail.com> Date: Sun, 3 Apr 2005 21:50:20 -0400 From: Elias Torres Reply-To: elias@torrez.us To: "Atom-Syntax Syntax'" Subject: Re: Why is alternate link a MUST? In-Reply-To: <42507689.9070703@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <20050402225748.GM30546@home.fastolfe.net> <424F5379.8010508@intertwingly.net> <20050403134559.GY6334@tartarus.org> <20050403172739.GN30546@home.fastolfe.net> <3f1451f5050403120638d8f259@mail.gmail.com> <0c469f336d2ee1f691f91b42de2f0e0c@sun.com> <42507689.9070703@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j341oLQJ014484 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I do think also that there are plenty of use cases suggesting that alternate might not be always available. However in that context where there's no feasible alternate, it would be extremely useful to know you can count on atom:id. If not, what else can you rely on to track your "content" as it flows from system to system without an alternate. I have not been following atom-syntax for a while, but are there any other elements that could be used if no alternate was not found? I think this is the reason why Sam has never seen anybody complain about link because, it doubles as id as well, but since we have a clear separation in atom, either or both might be good to be specified. Just my two cents. Elias Torres On Apr 3, 2005 7:04 PM, Bill de hÓra wrote: > > Tim Bray wrote: > > > > On Apr 3, 2005, at 12:45 PM, Graham wrote: > > > >> So do you have an argument here as to why it should be required? All > >> I'm seeing is that it's easy to workaround when the publisher omits it. > > > > > > Agreed. Joe, that wasn't very convincing. I repeat, we've seen several > > very believable use-cases for why someone might want this, and no good > > arguments (that I can remember) that it would break anything. Sam has > > pointed out that no previous version of RSS has done this, which is a > > reasonable argument; except for we have use-cases, and nobody's shown > > that the cost is non-zero. -Tim > > The top level feed stuff doesn't make a lot of sense to me. That > @alternate is mandatory while @self and atom:id are not isn't very > convincing either: > > atom:link[@rel='alternate'] : MUST > atom:link[@rel='self'] : SHOULD > atom:id : MAY > > You can't have a useful discussion about @alternate without talking > about @self or atom:id. > > Thus: I'm -1 to downgrading @alternate unless @self is lifted to MUST or > atom:id is lifted to MUST. If either are lifted to must I'm 0 on > downgrading @alternate. At that stage @alternate doesn't matter a whole lot. > > cheers > Bill > > From owner-atom-syntax@mail.imc.org Mon Apr 4 09:52:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08245 for ; Mon, 4 Apr 2005 09:52:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34DhOi4028211; Mon, 4 Apr 2005 06:43:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34DhOow028210; Mon, 4 Apr 2005 06:43:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34DhNsl028194 for ; Mon, 4 Apr 2005 06:43:23 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id f1so1866571rne for ; Mon, 04 Apr 2005 06:43:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=uMMWosMQJiztqh43MWalSnwQwJI+GfZuzVOJ5KPt+DdO/1OpE644VkphzBDaEdm2VU/wqjpZaC38wuEM6Q6SLOqDucSaLjlVdLpy3P6VyvInZWHUeSpxrEHEt9qXoMZgYg0gaEatkdTiqlCCHJNdcJ2M4h8ok0FLfzq1r2OS0Vc= Received: by 10.38.161.30 with SMTP id j30mr468731rne; Mon, 04 Apr 2005 06:43:22 -0700 (PDT) Received: by 10.38.151.18 with HTTP; Mon, 4 Apr 2005 06:43:22 -0700 (PDT) Message-ID: <3f1451f50504040643189c1b71@mail.gmail.com> Date: Mon, 4 Apr 2005 09:43:22 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Robert Sayre Subject: Re: Why is alternate link a MUST? Cc: Paul Hoffman , Atom Syntax In-Reply-To: <4250BBB9.9030009@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <4250BBB9.9030009@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 3, 2005 11:59 PM, Robert Sayre wrote: > > Paul Hoffman wrote: > > > > > What is the technical reasons for the SHOULDs and MUSTs? Where is the > > interoperability issues within the protocol (not with readers that don't > > know what the protocol looks like)? What are the potentials for causing > > harm? I'm not saying there are none; I'm saying let's choose our levels > > based on what we are supposed to be choosing from. > > If none of them are MUST, there is no social recourse when tracking down > problems or seeking social understanding. Where did this feed come from? > Who makes alternates? What's this all about? +1 Of course, if link@alternate is not the identifier and it falls to atom:id then we may end up having to add more verbage to the spec. For example, today some feeds are full-content, others are abbreviated. If I produce both kinds of feeds, do I use the same atom:id for both? What if one feed is delivered via email and the other via HTTP, should they both use the same atom:id? -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Apr 4 10:37:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13763 for ; Mon, 4 Apr 2005 10:37:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34EVqU6033207; Mon, 4 Apr 2005 07:31:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34EVqIP033206; Mon, 4 Apr 2005 07:31:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34EVo8u033199 for ; Mon, 4 Apr 2005 07:31:51 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4250BBB9.9030009@franklinmint.fm> References: <4250BBB9.9030009@franklinmint.fm> Date: Mon, 4 Apr 2005 07:31:51 -0700 To: Atom Syntax From: Paul Hoffman Subject: Re: Why is alternate link a MUST? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:59 PM -0400 4/3/05, Robert Sayre wrote: >If none of them are MUST, there is no social recourse when tracking >down problems or seeking social understanding. Where did this feed >come from? Who makes alternates? What's this all about? Good, we're making progress. You're aiming at the "to limit behavior which has potential for causing harm" part of 2119. I'm fine with making one of them a MUST for that reason. atom:id seems like the one that would most help tracking down problems, yes? At 4:13 PM -0700 4/3/05, Tim Bray wrote: >I think is a SHOULD, to address >auto-subscriptions, one of the current #1 RSS pain points, perceived >by users as a failure to interoperate. -Tim Sounds good to me. At 2:25 PM +1000 4/4/05, Eric Scheid wrote: >ps. I think it would be prudent to put the reason why something is a SHOULD >in the spec itself. +1. There is ample evidence in the IETF that, when you don't do that, people will guess wrong about a year after the spec comes out. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Apr 4 10:37:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13808 for ; Mon, 4 Apr 2005 10:37:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34ESRh2032926; Mon, 4 Apr 2005 07:28:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34ESRMK032925; Mon, 4 Apr 2005 07:28:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34ESPPJ032902; Mon, 4 Apr 2005 07:28:26 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.2.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j34EPZaE021133; Mon, 4 Apr 2005 15:25:35 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4098bcc50b10543cc272631e0ed15398@mac.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Graham Subject: Re: Why is alternate link a MUST? Date: Mon, 4 Apr 2005 15:25:44 +0100 To: Paul Hoffman X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 Apr 2005, at 4:32 am, Paul Hoffman wrote: > This isn't a negotiating game. We have to have technical reasons for > our assigning requirements levels. Right: 1. Feed level ids. By all reasonable web conventions, requesting a feed from a particular URI can be expected to only ever return one particular feed resource. Whereas, the request will also return an essentially random combination of entry resources. Entry ids are a MUST because of the latter, which doesn't apply to feeds. A separate feature of entry or feed ids is comparison and duplicate-removal across URIs. Since many users/implementers may choose not to do this due to concerns over security and potentially unexpected-behaviour, it can be described as "truly optional" functionality, which makes it MAY. 2. Link rel=self Subscribing to feeds is a fundamental feature, and since the whole purpose of "self" is to make it simple and reliable, this element is not optional, and it's reasonable to say it must be present. But I can think of a few edge cases where the service generating the XML may not know its eventual URI, and of course there may be circumstances where there isn't one. This is the only reason I can think of to omit it. Since "SHOULD" allows implementers to wimp out for any reason they choose, I think the appropriate wording is "MUST where one exists and is known". 3. Link rel=alternate Sorry Sam, but this is "truly optional" as per MAY. Being able to click back to the home page is nice, but how is it an "absolute requirement"? Graham From owner-atom-syntax@mail.imc.org Mon Apr 4 11:01:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15714 for ; Mon, 4 Apr 2005 11:01:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34EuPmO035276; Mon, 4 Apr 2005 07:56:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34EuPut035275; Mon, 4 Apr 2005 07:56:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34EuOwb035263 for ; Mon, 4 Apr 2005 07:56:24 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.2.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j34Ernx0006918; Mon, 4 Apr 2005 15:53:49 +0100 (BST) In-Reply-To: <4250BBB9.9030009@franklinmint.fm> References: <4250BBB9.9030009@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Graham Subject: Re: Why is alternate link a MUST? Date: Mon, 4 Apr 2005 15:54:00 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 Apr 2005, at 4:59 am, Robert Sayre wrote: > If none of them are MUST, there is no social recourse when tracking > down problems or seeking social understanding. Where did this feed > come from? Well, things don't just appear, do they: If it arrived over HTTP: You should know, you requested it. From a server with whois information and port 25 and a front page and a million other things. If it arrived over email: The from address. If you found it on a local disk: Somebody put it there. There's no guarantee that alternate points anywhere useful. If you want to write up a proposal suggesting a required, verified troubleshooting contact, please do, but don't use it to justify something unrelated. Graham From owner-atom-syntax@mail.imc.org Mon Apr 4 11:10:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16677 for ; Mon, 4 Apr 2005 11:10:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34F1PlI035755; Mon, 4 Apr 2005 08:01:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34F1Plx035754; Mon, 4 Apr 2005 08:01:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34F1OxR035747 for ; Mon, 4 Apr 2005 08:01:24 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j34F2vaL028728 for ; Mon, 4 Apr 2005 11:03:01 -0400 Message-ID: <425156BB.8090503@intertwingly.net> Date: Mon, 04 Apr 2005 11:01:15 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: PaceFeedIdOrAlternate References: <4250BBB9.9030009@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceFeedIdOrAlternate Background: there seems to be some feeling that *something* should be required. Opinions vary from id should be a MUST to id is at best a MAY. While there are use cases for feeds without alternate html representations, I've been concerned that they are such outliers that the would be mostly ignored by the predominant feed producers; with the inevitable result that such feeds would be poorly handled and would therefore reflect poorly on both the authors of such feeds and the feed format itself. As this issue keeps coming up, this concern is lessening for me. Notes: this pace was written in such a way to minimize the amount of change to the existing document. It does not express a preference between the two elements. Upgrading one or both elements to a SHOULD would require a separate Pace. Upgrading the Self link to a SHOULD or MUST would require a separate Pace. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Apr 4 11:25:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18022 for ; Mon, 4 Apr 2005 11:25:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FImTv037628; Mon, 4 Apr 2005 08:18:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34FImrP037627; Mon, 4 Apr 2005 08:18:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FIlnR037615 for ; Mon, 4 Apr 2005 08:18:48 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc13) with SMTP id <2005040415182701600rvnvee>; Mon, 4 Apr 2005 15:18:38 +0000 Date: Mon, 4 Apr 2005 09:18:30 -0600 Subject: Re: Why is alternate link a MUST? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <42507967.2000105@franklinmint.fm> Message-Id: X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j34FImnR037622 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sunday, April 3, 2005, at 05:16 PM, Robert Sayre wrote: > Tim Bray wrote: >> Well, yeah, but when they do the half-hour's coding it's going to >> cost them to start supporting Real IETF Atom 1.00 (tm), they can do >> an extra 3 minutes and if there's no , they don't make the >> subscription clickable. > > I doubt they've never encountered a feed without a link. Why do you > think they didn't fix it? Perhaps a combination of: * Because the RSS spec says its required * Because it doesn't cause any serious problems like a computer or application crash, just an unexpected page to be shown when the link is clicked * Because nobody who we assume pointed it out to them complained loudly since it didn't cause any serious problems * Because they had more important things to do Both the amount of work required to enable an app to handle linkless feeds and the negative impact of not having the link are trivial as far as I can see, except for Bill's point about wanting an identifier for the feed. On Monday, April 4, 2005, at 06:25 AM, Bill de hÓra wrote: > Anyway I've made my position clear at this point. Please make id or > self mandatory. I'd be opposed to link[@rel="self"] or link[@rel="alternate"] being mandatory since uses cases have been put forth for not having a reasonable value for either, but not opposed to either or both being SHOULDs. I also wouldn't be opposed to a feed being required to have either a link[@rel="self"] or an id. From owner-atom-syntax@mail.imc.org Mon Apr 4 11:33:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19086 for ; Mon, 4 Apr 2005 11:33:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FR6RF038320; Mon, 4 Apr 2005 08:27:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34FR6RY038319; Mon, 4 Apr 2005 08:27:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FR5gd038309 for ; Mon, 4 Apr 2005 08:27:05 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc11) with SMTP id <2005040415265701300dkm8ke>; Mon, 4 Apr 2005 15:26:57 +0000 Date: Mon, 4 Apr 2005 09:26:53 -0600 Subject: Re: Why is alternate link a MUST? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <54e33e44.3e4454e3@ims1.labs.mot.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sunday, April 3, 2005, at 11:05 AM, Brett Lindsley wrote: > Consider a feed returned as a result of a search operation (e.g. > a time range). To create an alternate representation of this > resource, the link must also specify the same conditions that > resulted in the search results. That is, the alternate link needs > to somehow embed the search conditions of the search that > created the feed so the server can provide an alternate > representation. One way to fix this would be to indicate in the > protocol spec that the same http headers must be provided to > the alternate link as those used to request the feed. If we want the link to point to something that's strictly an alternative representation of the same data, then that makes sense, but it seems to me that the link is pointing to another view into the same data stream, which could be different in more ways than just the data format. For example, following the alternate link may get you a homepage containing entries that were added after you downloaded the feed. In that case, the homepage is certainly not an alternative representation of the same data. Just as the feed or homepage contents may be different depending on when you access them, I think our definition of "alternate" is loose enough to allow differences based on HTTP headers. From owner-atom-syntax@mail.imc.org Mon Apr 4 11:48:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20340 for ; Mon, 4 Apr 2005 11:48:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FdmIR039355; Mon, 4 Apr 2005 08:39:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34FdmSP039354; Mon, 4 Apr 2005 08:39:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FdmNP039348 for ; Mon, 4 Apr 2005 08:39:48 -0700 (PDT) (envelope-from brett.lindsley@labs.mot.com) Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j34FikPf011684 for ; Mon, 4 Apr 2005 08:44:46 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j34Ff6cm006022 for ; Mon, 4 Apr 2005 10:41:06 -0500 (CDT) Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j34Fdktv006267 for ; Mon, 4 Apr 2005 10:39:46 -0500 (CDT) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0IEF007HGI6AQB@ims1.labs.mot.com> for atom-syntax@imc.org; Mon, 04 Apr 2005 10:39:46 -0500 (CDT) Date: Mon, 04 Apr 2005 10:39:40 -0500 From: Brett Lindsley Subject: Re: Why is alternate link a MUST? To: atom-syntax@imc.org Message-id: <42515FBC.3060300@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT How about a link[@rel="homepage"] for feeds that actually have a home page to point to. By the same reasoning, link[@rel="alternate"] would exist if the feed actually had an alternate representation. Both of these would be MAY. This would be consistent with how the spec currently treats the prev, next, etc. with the verbage "atom:feed elements MAY contain additional atom:link elements beyond those described above" Sec 4.1.1. If all of these links are MAY, then the only effect of the client is the ability to have more features if they are included. I can't think of an example where the client would fail to function if one if them would be excluded (no reason for a MUST). Antone Roundy wrote: > > On Sunday, April 3, 2005, at 05:16 PM, Robert Sayre wrote: > >> Tim Bray wrote: >> >>> Well, yeah, but when they do the half-hour's coding it's going to >>> cost them to start supporting Real IETF Atom 1.00 (tm), they can do >>> an extra 3 minutes and if there's no , they don't make the >>> subscription clickable. >> >> >> I doubt they've never encountered a feed without a link. Why do you >> think they didn't fix it? > > > Perhaps a combination of: > > * Because the RSS spec says its required > * Because it doesn't cause any serious problems like a computer or > application crash, just an unexpected page to be shown when the link > is clicked > * Because nobody who we assume pointed it out to them complained > loudly since it didn't cause any serious problems > * Because they had more important things to do > > Both the amount of work required to enable an app to handle linkless > feeds and the negative impact of not having the link are trivial as > far as I can see, except for Bill's point about wanting an identifier > for the feed. > > On Monday, April 4, 2005, at 06:25 AM, Bill de hÓra wrote: > >> Anyway I've made my position clear at this point. Please make id or >> self mandatory. > > > I'd be opposed to link[@rel="self"] or link[@rel="alternate"] being > mandatory since uses cases have been put forth for not having a > reasonable value for either, but not opposed to either or both being > SHOULDs. I also wouldn't be opposed to a feed being required to have > either a link[@rel="self"] or an id. > > From owner-atom-syntax@mail.imc.org Mon Apr 4 11:49:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20426 for ; Mon, 4 Apr 2005 11:49:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34FhfFx039670; Mon, 4 Apr 2005 08:43:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34FhfTJ039669; Mon, 4 Apr 2005 08:43:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34Fhenh039656; Mon, 4 Apr 2005 08:43:40 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12ld22h.cable.mindspring.com ([69.86.136.81] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DITjj-0000Ip-8L; Mon, 04 Apr 2005 15:43:36 +0000 Message-ID: <425160AA.8040504@franklinmint.fm> Date: Mon, 04 Apr 2005 11:43:38 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Atom Syntax Subject: Re: Why is alternate link a MUST? References: <4250BBB9.9030009@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > > At 11:59 PM -0400 4/3/05, Robert Sayre wrote: > >> If none of them are MUST, there is no social recourse when tracking >> down problems or seeking social understanding. Where did this feed >> come from? Who makes alternates? What's this all about? > > > Good, we're making progress. Not really. We get to design our protocol, and we know the type of software that will be consuming a large part of the traffic. All of that software expects a feed-level link. There are use cases where that's awkward, but I can't believe people want to put these out on the open Internet without an alternate. > You're aiming at the "to limit behavior > which has potential for causing harm" part of 2119. > > I'm fine with making one of them a MUST for that reason. atom:id seems > like the one that would most help tracking down problems, yes? Nope. That could very well be a non-heirarchical scheme like urn:uuid. This is not necessarily about full-on buggy software. Making atom:id mandatory does seem low-cost; if the producer can't do it once, they'll never do it for the entries. There are lots of situations where the software is behaving correctly but the content is confusing to the end-user. Feed-level links help to resolve that confusion. Without the link, non-bugs become a problem. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Apr 4 12:31:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24975 for ; Mon, 4 Apr 2005 12:31:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34GMLpH043149; Mon, 4 Apr 2005 09:22:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34GMLOk043148; Mon, 4 Apr 2005 09:22:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34GMKOa043136 for ; Mon, 4 Apr 2005 09:22:21 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc11) with SMTP id <2005040416221301300dk3c1e>; Mon, 4 Apr 2005 16:22:13 +0000 Date: Mon, 4 Apr 2005 10:22:13 -0600 Subject: Re: Why is alternate link a MUST? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <425160AA.8040504@franklinmint.fm> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Monday, April 4, 2005, at 09:43 AM, Robert Sayre wrote: > I can't believe people want to put these out on the open Internet > without an alternate. Feeds are the only kind of resource on the internet that I'm aware of that routinely have alternate representations. Thinking about it from that direction, why one WOULD want a feed to have an alternate representation becomes a more important question than would one WOULDN'T. Here are the reasons I can think of: * Feeds emerged in the context of an internet where virtually everybody had a web browser, but virtually no one had a feed reader. Having only a feed severely limited one's reach. * Feeds emerged in the context of an internet where publishers were already publishing HTML representations of the data they started putting into feeds. * Feeds began as a method of announcing the existence of new data on web pages, not as a method of delivering full content. * There are established and accepted methods of building revenue streams from web pages--ie, we know where to put ads in web pages. Until people figure out how to monetize their feeds, many will want to use them to drive people to their web pages. It seems to me that the reasons for having alternate links in feeds are almost entirely based on the context in which feeds originally emerged. These conditions still apply to many feeds, but not all. I don't see any reason to try to force feeds to continue to be the unusual internet resource that always has an alternate representation. Antone From owner-atom-syntax@mail.imc.org Mon Apr 4 12:43:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26392 for ; Mon, 4 Apr 2005 12:43:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34Gc1Mk044742; Mon, 4 Apr 2005 09:38:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34Gc1EZ044741; Mon, 4 Apr 2005 09:38:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34Gc0lP044731 for ; Mon, 4 Apr 2005 09:38:01 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc13) with SMTP id <2005040416375001600rtadve>; Mon, 4 Apr 2005 16:37:50 +0000 Date: Mon, 4 Apr 2005 10:37:53 -0600 Subject: Re: PaceFeedIdOrAlternate Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <425156BB.8090503@intertwingly.net> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think requiring either atom:id or atom:link[@rel="self"] would make more sense. It's entirely conceivable that multiple feeds might exist that claim to be alternates of the same resource--for example, a full content feed vs. a summary feed; a scraped feed vs. an official feed (...in which case, the scraped feed might be a copyright violation, but that's a separate matter); a feed of the tech news entries in a blog vs. a feed of the personal entries in the same blog; etc. Requiring id or self would ensure that consumers had a somewhat reliable value to use as an identifier for each feed. Alternate, on the other hand, may not be useful as an identifier, so it really doesn't fill the same space as id, and thus it doesn't make sense to me to use those two as alternatives for filling a feed requirement. Antone On Monday, April 4, 2005, at 09:01 AM, Sam Ruby wrote: > http://www.intertwingly.net/wiki/pie/PaceFeedIdOrAlternate > > Background: there seems to be some feeling that *something* should be > required. Opinions vary from id should be a MUST to id is at best a > MAY. > > While there are use cases for feeds without alternate html > representations, I've been concerned that they are such outliers that > the would be mostly ignored by the predominant feed producers; with > the inevitable result that such feeds would be poorly handled and > would therefore reflect poorly on both the authors of such feeds and > the feed format itself. As this issue keeps coming up, this concern > is lessening for me. > > Notes: this pace was written in such a way to minimize the amount of > change to the existing document. It does not express a preference > between the two elements. Upgrading one or both elements to a SHOULD > would require a separate Pace. Upgrading the Self link to a SHOULD or > MUST would require a separate Pace. > > - Sam Ruby > From owner-atom-syntax@mail.imc.org Mon Apr 4 12:48:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26992 for ; Mon, 4 Apr 2005 12:48:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34GfrMc045007; Mon, 4 Apr 2005 09:41:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34GfrIK045006; Mon, 4 Apr 2005 09:41:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34GfreG044999 for ; Mon, 4 Apr 2005 09:41:53 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 55078 invoked by uid 17064); 4 Apr 2005 16:41:53 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.141.135]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 4 Apr 2005 16:41:53 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <35d3c517586a20da82c1f236049345a3@bblfish.net> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: Henry Story Subject: Re: Why is alternate link a MUST? Date: Mon, 4 Apr 2005 18:41:50 +0200 To: Antone Roundy X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This is very convincing to me. Henry On 4 Apr 2005, at 18:22, Antone Roundy wrote: > On Monday, April 4, 2005, at 09:43 AM, Robert Sayre wrote: >> I can't believe people want to put these out on the open Internet >> without an alternate. > Feeds are the only kind of resource on the internet that I'm aware of > that routinely have alternate representations. Thinking about it from > that direction, why one WOULD want a feed to have an alternate > representation becomes a more important question than would one > WOULDN'T. Here are the reasons I can think of: > > * Feeds emerged in the context of an internet where virtually > everybody had a web browser, but virtually no one had a feed reader. > Having only a feed severely limited one's reach. > * Feeds emerged in the context of an internet where publishers were > already publishing HTML representations of the data they started > putting into feeds. > * Feeds began as a method of announcing the existence of new data on > web pages, not as a method of delivering full content. > * There are established and accepted methods of building revenue > streams from web pages--ie, we know where to put ads in web pages. > Until people figure out how to monetize their feeds, many will want to > use them to drive people to their web pages. > > It seems to me that the reasons for having alternate links in feeds > are almost entirely based on the context in which feeds originally > emerged. These conditions still apply to many feeds, but not all. I > don't see any reason to try to force feeds to continue to be the > unusual internet resource that always has an alternate representation. > > Antone > From owner-atom-syntax@mail.imc.org Mon Apr 4 13:09:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29172 for ; Mon, 4 Apr 2005 13:09:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34H2atC047627; Mon, 4 Apr 2005 10:02:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34H2aQb047626; Mon, 4 Apr 2005 10:02:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34H2Zxk047617 for ; Mon, 4 Apr 2005 10:02:36 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.3]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DIUy7-0001Zh-GQ; Mon, 04 Apr 2005 17:02:31 +0000 Message-ID: <4251732C.9060807@franklinmint.fm> Date: Mon, 04 Apr 2005 13:02:36 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: Why is alternate link a MUST? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > On Monday, April 4, 2005, at 09:43 AM, Robert Sayre wrote: > >> I can't believe people want to put these out on the open Internet >> without an alternate. > > It seems to me that the reasons for having alternate links in feeds are > almost entirely based on the context in which feeds originally emerged. This isn't a good time for conjecture. I don't think any of the arguments in favor have considered the support burden such feeds will create. OTOH, the absolute worst thing to do right now would be to sit around and argue this for a week. I'm very opposed to getting inventive and making this a MAY. I'm not changing my mind, but the group will probably just define it over my objection. Happens all the time :) Robert Sayre From owner-atom-syntax@mail.imc.org Mon Apr 4 13:09:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29222 for ; Mon, 4 Apr 2005 13:09:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34H0OvM047110; Mon, 4 Apr 2005 10:00:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34H0OBE047107; Mon, 4 Apr 2005 10:00:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34H0NjY047099 for ; Mon, 4 Apr 2005 10:00:24 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1DIUw1-0000RN-00; Mon, 04 Apr 2005 18:00:21 +0100 Date: Mon, 4 Apr 2005 18:00:21 +0100 From: James Aylett To: Atom Syntax Subject: Re: Why is alternate link a MUST? Message-ID: <20050404170021.GG22458@tartarus.org> Mail-Followup-To: James Aylett , Atom Syntax References: <4250BBB9.9030009@franklinmint.fm> <425160AA.8040504@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425160AA.8040504@franklinmint.fm> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Apr 04, 2005 at 11:43:38AM -0400, Robert Sayre wrote: > We get to design our protocol, and we know the type of software that > will be consuming a large part of the traffic. All of that software > expects a feed-level link. There are use cases where that's awkward, > but I can't believe people want to put these out on the open > Internet without an alternate. Depends what you mean by "the open Internet": what about password-protected web products? Also, there's an implication here that we don't care about making life hard for denizens of "the closed Internet", giving them the choice between abusing Atom and choosing something entirely different. I have yet to hear a reason to make alternate a MUST that is compelling. That existing software (which by definition can't be an IETF Atom client) expects a link to ... some kind of HTML ... doesn't cut it for me, not least because the current atom-syntax spec doesn't require a link to some kind of HTML at all anyway. At the end of the day, I don't think it's possible to make the question "is X an alternate version of Y" anything other than a subjective call. As such, I don't see the value of making it a MUST - forcing to export their opinions isn't /always/ the purpose of a blog format :-) James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Mon Apr 4 14:09:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06885 for ; Mon, 4 Apr 2005 14:09:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34HxX0C052328; Mon, 4 Apr 2005 10:59:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34HxXrZ052327; Mon, 4 Apr 2005 10:59:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34HxWEL052315 for ; Mon, 4 Apr 2005 10:59:33 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc11) with SMTP id <2005040417592501300dltvse>; Mon, 4 Apr 2005 17:59:25 +0000 Date: Mon, 4 Apr 2005 11:59:26 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceFeedIdOrSelf From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <4862F38A-A533-11D9-8787-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceFeedIdOrSelf Note that this proposal makes alternate a SHOULD, not a MAY. This is to say that if you've got an alternate, you SHOULD link to it. I don't particularly care whether that's SHOULD or MAY. =============== Abstract Require either a self link or an id as children of atom:feed elements. Don't require an alternate link. Rationale * From PaceFeedIdOrAlternate: A number of use cases (e.g., [WWW]subversion change logs and [WWW]email attachments) have been defined in which there is no alternate html representation. * Lacking an atom:id, the self link is the most reliable data to use as an identifier for a feed, making it a better alternative to atom:id than an alternate link. * Feeds may be the only type of internet resource that routinely have an alternate representation. While this convention arose naturally during the emergence of feed formats, no strong argument has been found for requiring this unique situation. Proposal In section 4.1.1 of atompub-format-06, change this: * atom:feed elements MUST contain at least one atom:link element with a relation of "alternate". To this: * atom:feed elements SHOULD contain at least one atom:link element with a relation of "alternate". And add this bullet point: * atom:feed elements that contain no child atom:id element MUST contain an atom:link element with a relation of "self". Impacts Tools which expect feed level links (such as [WWW]Bloglines) will need to be prepared for the absense of this information. From owner-atom-syntax@mail.imc.org Mon Apr 4 14:33:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09881 for ; Mon, 4 Apr 2005 14:33:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34IIpTq053698; Mon, 4 Apr 2005 11:18:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34IIpV5053697; Mon, 4 Apr 2005 11:18:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34IIoJx053685 for ; Mon, 4 Apr 2005 11:18:51 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j34IHHmt008697; Mon, 4 Apr 2005 19:17:23 +0100 (BST) In-Reply-To: <4251732C.9060807@franklinmint.fm> References: <4251732C.9060807@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9bdb85772fbeb73452c19bfe3d4fd6d4@mac.com> Content-Transfer-Encoding: 7bit Cc: "Atom-Syntax Syntax'" From: Graham Subject: Re: Why is alternate link a MUST? Date: Mon, 4 Apr 2005 19:17:05 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 Apr 2005, at 6:02 pm, Robert Sayre wrote: > This isn't a good time for conjecture. I don't think any of the > arguments in favor have considered the support burden such feeds will > create. Basically none. I have no clue why you're raising this objection given all the other functionality we're adding or replacing. Links now being optional is right at the bottom of the list of changes people will have to make. Graham From owner-atom-syntax@mail.imc.org Mon Apr 4 15:49:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18663 for ; Mon, 4 Apr 2005 15:49:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34JfF0k061128; Mon, 4 Apr 2005 12:41:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34JfFjX061127; Mon, 4 Apr 2005 12:41:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34JfEgT061119 for ; Mon, 4 Apr 2005 12:41:14 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16006; Mon, 4 Apr 2005 15:41:11 -0400 (EDT) Message-Id: <200504041941.PAA16006@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: atom-syntax@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atompub-format-07.txt Date: Mon, 04 Apr 2005 15:41:11 -0400 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : The Atom Syndication Format Author(s) : M. Nottingham, R. Sayre Filename : draft-ietf-atompub-format-07.txt Pages : 50 Date : 2005-4-4 This document specifies Atom, an XML-based Web content and metadata syndication format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atompub-format-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-atompub-format-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-4161110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atompub-format-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atompub-format-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-4161110.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-atom-syntax@mail.imc.org Mon Apr 4 15:54:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20813 for ; Mon, 4 Apr 2005 15:54:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34JlMFD061642; Mon, 4 Apr 2005 12:47:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34JlMit061641; Mon, 4 Apr 2005 12:47:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j34JlLgl061624 for ; Mon, 4 Apr 2005 12:47:21 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 92795 messnum 5267320 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 4 Apr 2005 19:47:14 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail04.svc.cra.dublin.eircom.net (qp 92795) with SMTP; 4 Apr 2005 19:47:14 -0000 Message-ID: <425199C1.2010007@dehora.net> Date: Mon, 04 Apr 2005 20:47:13 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: Why is alternate link a MUST? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Eric Scheid wrote: > On 4/4/05 10:25 PM, "Bill de hÓra" wrote: > > >>Anyway I've made my position clear at this point. Please make id or self >>mandatory. > > > atom:id then, since atom:link[@rel='self'] could change at any point in > time, and mutability is not a good attribute of an identifier. Yes, your other post convinced me that atom:link[@rel='self'] needs to be optional. cheers Bill From owner-atom-syntax@mail.imc.org Mon Apr 4 16:23:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29569 for ; Mon, 4 Apr 2005 16:23:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34KG8kK064380; Mon, 4 Apr 2005 13:16:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34KG8Pd064379; Mon, 4 Apr 2005 13:16:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34KG75B064371 for ; Mon, 4 Apr 2005 13:16:07 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DIXzO-0003mQ-W9; Mon, 04 Apr 2005 20:16:03 +0000 Message-ID: <4251A088.8000408@franklinmint.fm> Date: Mon, 04 Apr 2005 16:16:08 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: i-d-announce@ietf.org, atom-syntax@imc.org Subject: Re: I-D ACTION:draft-ietf-atompub-format-07.txt References: <200504041941.PAA16006@ietf.org> In-Reply-To: <200504041941.PAA16006@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Some other URIs for this I-D: http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html http://atompub.org/2005/04/04/draft-ietf-atompub-format-07-from-6.diff.html Robert Sayre Internet-Drafts@ietf.org wrote: > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-07.txt From owner-atom-syntax@mail.imc.org Mon Apr 4 16:58:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08258 for ; Mon, 4 Apr 2005 16:58:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j34KtgRN067710; Mon, 4 Apr 2005 13:55:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j34KtfGR067709; Mon, 4 Apr 2005 13:55:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j34Kte01067692 for ; Mon, 4 Apr 2005 13:55:41 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 04 Apr 2005 20:55:33 -0000 Received: from pD9E6291C.dip.t-dialin.net (EHLO [192.168.0.4]) [217.230.41.28] by mail.gmx.net (mp026) with SMTP; 04 Apr 2005 22:55:33 +0200 X-Authenticated: #1915285 Message-ID: <4251A9BA.6050905@gmx.de> Date: Mon, 04 Apr 2005 22:55:22 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceFeedIdOrSelf References: <4862F38A-A533-11D9-8787-003065EA6144@geckotribe.com> In-Reply-To: <4862F38A-A533-11D9-8787-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > ... > Proposal > > In section 4.1.1 of atompub-format-06, change this: > > * atom:feed elements MUST contain at least one atom:link element > with a relation of "alternate". > > To this: > > * atom:feed elements SHOULD contain at least one atom:link element > with a relation of "alternate". +1 (I just checked my two test feeds; one of which doesn't have an "alternate" version so currently I have to lie). > And add this bullet point: > > * atom:feed elements that contain no child atom:id element MUST > contain an atom:link element with a relation of "self". Fine with me as well. > ... Best regards, Julian From owner-atom-syntax@mail.imc.org Tue Apr 5 05:42:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29920 for ; Tue, 5 Apr 2005 05:42:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j359VvR4002704; Tue, 5 Apr 2005 02:31:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j359VvWU002703; Tue, 5 Apr 2005 02:31:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j359VuR9002670 for ; Tue, 5 Apr 2005 02:31:56 -0700 (PDT) (envelope-from jalkanen@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so3387053wri for ; Tue, 05 Apr 2005 02:31:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ipYnQ2KHBhrlYamVY/ZO5JNtzOj1kOqxxNnd4EUh4ERJNYxmrVDiJ3jnKOKqbx7eqPq0OSXBkZ2O9Goi9jQ6LHJ86iUqmGIqP6M17ZB2dTMDiET9XxW166UTLnAl8DjwvW7qSG3k73AJOAvrOARgTbrbFi3dQeOtL7LUBvG+8Wg= Received: by 10.54.28.31 with SMTP id b31mr484193wrb; Tue, 05 Apr 2005 02:31:50 -0700 (PDT) Received: by 10.54.28.37 with HTTP; Tue, 5 Apr 2005 02:31:50 -0700 (PDT) Message-ID: <7aebae7d05040502314b9cb62e@mail.gmail.com> Date: Tue, 5 Apr 2005 12:31:50 +0300 From: Janne Jalkanen Reply-To: Janne Jalkanen To: Atom WG Subject: Fwd: PaceFeedIdOrSelf In-Reply-To: <7aebae7d050405023168d962e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <4862F38A-A533-11D9-8787-003065EA6144@geckotribe.com> <4251A9BA.6050905@gmx.de> <7aebae7d050405023168d962e@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This 23()=(#"=)( GMail, I always send to the author instead of the list... Sorry, Julian. ---------- Forwarded message ---------- From: Janne Jalkanen Date: Apr 5, 2005 12:31 PM Subject: Re: PaceFeedIdOrSelf To: Julian Reschke +1. Also, a second question on enclosures: if you have a in your , I read it that you MUST also have a , if there is no -element? So putting plain enclosures requires also some content... Necessary? Yes? No? /Janne From owner-atom-syntax@mail.imc.org Tue Apr 5 05:56:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01063 for ; Tue, 5 Apr 2005 05:56:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j359nC4v008422; Tue, 5 Apr 2005 02:49:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j359nCe5008421; Tue, 5 Apr 2005 02:49:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j359nBHh008383 for ; Tue, 5 Apr 2005 02:49:11 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j359n3719679; Tue, 5 Apr 2005 18:49:03 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id c73b3b0c_a5b7_11d9_9b09_0030482533a1_19533; Tue, 05 Apr 2005 18:47:52 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO001240; 5 Apr 05 18:49:52 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 5 Apr 05 18:49:48 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.21) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG00123F; 5 Apr 05 18:49:46 +0900 Message-Id: <6.0.0.20.2.20050405184833.080101a0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 05 Apr 2005 18:48:48 +0900 To: Antone Roundy , atom-syntax@imc.org From: Martin Duerst Subject: Re: PaceFeedIdOrSelf In-Reply-To: <4862F38A-A533-11D9-8787-003065EA6144@geckotribe.com> References: <4862F38A-A533-11D9-8787-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 At 02:59 05/04/05, Antone Roundy wrote: > >http://www.intertwingly.net/wiki/pie/PaceFeedIdOrSelf From owner-atom-syntax@mail.imc.org Tue Apr 5 11:48:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02674 for ; Tue, 5 Apr 2005 11:48:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35Fe4EV083745; Tue, 5 Apr 2005 08:40:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35Fe42u083744; Tue, 5 Apr 2005 08:40:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35Fe3cM083738 for ; Tue, 5 Apr 2005 08:40:03 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 05 Apr 2005 11:40:02 -0400 id 00590082.4252B152.000043D6 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: atom-syntax@imc.org Subject: AD Review Comments and Questions: draft-ietf-atompub-format-07 Date: Tue, 5 Apr 2005 11:39:47 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j35Fe3cM083739 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Your working group chairs have asked me to shepherd draft-ietf-atompub-format-07 through IETF last call. As part of that process, I have an obligation to review the document myself. I've completed my review and I'd like to share my comments and a few questions with the group. A new version of the document is probably needed before I can submit the last call request. I don't think I found any major problems, but I'd prefer to close known issues before asking the community for input -- especially since this working group has never met at a face-to-face IETF meeting. I intend to ask the XML Directorate to review the document during the last call period. Anything they find can be dealt with along with any other last call comments. Comments/Questions: The document includes an informative RELAX NG schema and several examples. What has been done to confirm that the schema is free of errors and that all of the examples given in the document are valid according to the schema? (I could check an XML Schema myself, but I don't have the tools I need to check RELAX NG.) Sections 1.1, 1.2: RFC 3688/BCP 81 describes IETF practice for naming XML namespaces. Why are namespace URIs (such as http://purl.org) that don't conform to this practice being used? Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt instead of RFC 2234 and confirm that everything that was valid before is still valid. The IESG approved this document as a Draft Standard last week. Section 2 describes a requirement for well-formedness, but it doesn't mention validity. I suspect that validity isn't a requirement given that the RELAX NG schema is informative, but it would be better if a specific statement were included to note that validity is not a requirement. Section 4: RFC 2045 is referenced. 2045 is on its way to being obsoleted by draft-freed-mime-p4 (in the RFC Editor queue) and draft-freed-media-type-reg (in last call). Can the more recent documents be referenced instead of 2045? The MIME media type registration template included in section 7 MUST be submitted to the ietf-types list (ietf-types@alvestrand.no) for review. A two-week review period is standard for requests to register new types in the standards tree. Please see the list archives [1] for samples if help is needed in crafting a review request and please send the request ASAP. Section 7.1: what process is the IESG supposed to use to review registration requests? Please see section 2 of RFC 2434/BCP 26 for mechanisms that might be used and please specify one in the document. -Scott- [1] http://eikenes.alvestrand.no/pipermail/ietf-types/ From owner-atom-syntax@mail.imc.org Tue Apr 5 12:14:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04950 for ; Tue, 5 Apr 2005 12:14:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35G524Z085516; Tue, 5 Apr 2005 09:05:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35G528R085515; Tue, 5 Apr 2005 09:05:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35G51p7085505 for ; Tue, 5 Apr 2005 09:05:01 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.8]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DIqXx-0001GA-5g; Tue, 05 Apr 2005 16:04:57 +0000 Message-ID: <4252B728.7050205@franklinmint.fm> Date: Tue, 05 Apr 2005 12:04:56 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Hollenbeck CC: atom-syntax@imc.org Subject: RNG and examples (was: AD Review Comments and Questions: draft-ietf-atompub-format-07) References: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Scott Hollenbeck wrote: > The document includes an informative RELAX NG schema and several examples. > What has been done to confirm that the schema is free of errors and that all > of the examples given in the document are valid according to the schema? (I > could check an XML Schema myself, but I don't have the tools I need to check > RELAX NG.) The draft is generated from an RFC2629 XML file which contains no schema fragments or examples. The schema fragments are generated from the full schema. To create the text version, the schema, fragments, and examples are inserted in a SAX pipeline, and xml2rfc.tcl generates the draft from the resulting document. Since the schema and examples are stored in separate files, it's easy to check them with a command-line validator. I use James Clark's Jing[0]. Robert Sayre [0] http://www.thaiopensource.com/relaxng/jing.html From owner-atom-syntax@mail.imc.org Tue Apr 5 12:27:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06298 for ; Tue, 5 Apr 2005 12:27:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35GKm9r086430; Tue, 5 Apr 2005 09:20:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35GKmXP086429; Tue, 5 Apr 2005 09:20:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35GKlLf086423 for ; Tue, 5 Apr 2005 09:20:47 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.8]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DIqn3-0001Kx-3P; Tue, 05 Apr 2005 16:20:33 +0000 Message-ID: <4252BAD0.6020503@franklinmint.fm> Date: Tue, 05 Apr 2005 12:20:32 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Scott Hollenbeck , atom-syntax@imc.org Subject: Re: RNG and examples References: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> <4252B728.7050205@franklinmint.fm> In-Reply-To: <4252B728.7050205@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > Scott Hollenbeck wrote: >> that all >> of the examples given in the document are valid according to the >> schema? Oh, you said *all*. The document fragments haven't been automatically checked, and I just spotted one mistake. The link element in 4.2.9.2 is broken. I'm not sure what we can do to ensure the small document fragments are valid, other than read them closely. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 5 12:33:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06844 for ; Tue, 5 Apr 2005 12:33:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35GPtYT086806; Tue, 5 Apr 2005 09:25:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35GPtDL086805; Tue, 5 Apr 2005 09:25:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35GPsLi086799 for ; Tue, 5 Apr 2005 09:25:54 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j35GPsX8017434 for ; Tue, 5 Apr 2005 10:25:54 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEH005CWEZ56K@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 05 Apr 2005 10:25:54 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEH00KIHEZ55E@mail.sun.net> for atom-syntax@imc.org; Tue, 05 Apr 2005 10:25:53 -0600 (MDT) Date: Tue, 05 Apr 2005 09:26:22 -0700 From: Tim Bray Subject: Re: AD Review Comments and Questions: draft-ietf-atompub-format-07 In-reply-to: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> To: Scott Hollenbeck Cc: atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 5, 2005, at 8:39 AM, Scott Hollenbeck wrote: > I intend to ask the XML Directorate to review the document during the > last > call period. Anything they find can be dealt with along with any > other last > call comments. For the WG's info: The Directorate is a volunteer group of alleged "XML experts" that reviews I-D's that use XML; I'm one of them, BTW. > The document includes an informative RELAX NG schema and several > examples. > What has been done to confirm that the schema is free of errors and > that all > of the examples given in the document are valid according to the > schema? (I > could check an XML Schema myself, but I don't have the tools I need to > check > RELAX NG.) Norm/Rob/Mark? > Sections 1.1, 1.2: RFC 3688/BCP 81 describes IETF practice for naming > XML > namespaces. Why are namespace URIs (such as http://purl.org) that > don't > conform to this practice being used? Our plan, as we discussed with you & Ted. last year, is to use a W3C namespace. The current value is a placeholder. Should we note this in -08? > Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt > instead > of RFC 2234 and confirm that everything that was valid before is still > valid. The IESG approved this document as a Draft Standard last week. Rob/Mark? > Section 2 describes a requirement for well-formedness, but it doesn't > mention validity. I suspect that validity isn't a requirement given > that > the RELAX NG schema is informative, but it would be better if a > specific > statement were included to note that validity is not a requirement. Hmm, I would say that validity isn't a requirement because the syntactic constraints are (we think) fully given in the text. The group consciously decided not to make the schema normative, for that reason. We do currently say that the schema is non-normative; having said that, a statement that there is no DTD and no validity requirement couldn't hurt. Rob/Mark? > Section 4: RFC 2045 is referenced. 2045 is on its way to being > obsoleted by > draft-freed-mime-p4 (in the RFC Editor queue) and > draft-freed-media-type-reg > (in last call). Can the more recent documents be referenced instead of > 2045? Rob/Mark? > The MIME media type registration template included in section 7 MUST be > submitted to the ietf-types list (ietf-types@alvestrand.no) for > review. A > two-week review period is standard for requests to register new types > in the > standards tree. Please see the list archives [1] for samples if help > is > needed in crafting a review request and please send the request ASAP. Scott, what's the scheduling on that? Do we launch that right now, independent of the rest of the document review process? > Section 7.1: what process is the IESG supposed to use to review > registration > requests? Please see section 2 of RFC 2434/BCP 26 for mechanisms that > might > be used and please specify one in the document. Paul, care to take the lead on this? -Tim From owner-atom-syntax@mail.imc.org Tue Apr 5 12:44:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07526 for ; Tue, 5 Apr 2005 12:44:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35Gbdmi087646; Tue, 5 Apr 2005 09:37:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35GbdUa087645; Tue, 5 Apr 2005 09:37:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j35Gbbq5087623 for ; Tue, 5 Apr 2005 09:37:38 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 05 Apr 2005 16:37:31 -0000 Received: from dsl-084-056-229-074.arcor-ip.net (EHLO localhost) [84.56.229.74] by mail.gmx.net (mp015) with SMTP; 05 Apr 2005 18:37:31 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Tim Bray Cc: atom-syntax@imc.org Subject: Re: AD Review Comments and Questions: draft-ietf-atompub-format-07 Date: Tue, 05 Apr 2005 18:37:54 +0200 Message-ID: <4259bdc2.368888593@smtp.bjoern.hoehrmann.de> References: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Tim Bray wrote: >Our plan, as we discussed with you & Ted. last year, is to use a W3C >namespace. The current value is a placeholder. Should we note this in >-08? Do you have a pointer to this? >> [draft-freed-media-type-reg] > >Rob/Mark? (Note that this is also a matter of reviewing the draft and checking that we took all differences into account). >> The MIME media type registration template included in section 7 MUST be >> submitted to the ietf-types list (ietf-types@alvestrand.no) for >> review. >Scott, what's the scheduling on that? Do we launch that right now, >independent of the rest of the document review process? We should announce this to ietf-xml-mime@imc.org aswell. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From owner-atom-syntax@mail.imc.org Tue Apr 5 13:06:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09201 for ; Tue, 5 Apr 2005 13:06:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35GvGw9088923; Tue, 5 Apr 2005 09:57:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35GvGIu088922; Tue, 5 Apr 2005 09:57:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35GvFoU088912 for ; Tue, 5 Apr 2005 09:57:15 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 05 Apr 2005 12:57:11 -0400 id 00590082.4252C367.0000564E Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: mint@franklinmint.fm Cc: atom-syntax@imc.org Subject: RE: RNG and examples (was: AD Review Comments and Questions: draft-ietf-atompub-format-07) Date: Tue, 5 Apr 2005 12:56:56 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749C98F@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <4252B728.7050205@franklinmint.fm> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert, Thanks, but you didn't answer all of my question. Has someone (you?) confirmed that the schema and examples are consistent? I really don't have the time to double-check something that the working group should have done itself if that means installing and getting familiar with a new software package. I saw your follow-up; thanks. -Scott- > -----Original Message----- > From: Robert Sayre [mailto:mint@franklinmint.fm] > Sent: Tuesday, April 05, 2005 12:05 PM > To: Scott Hollenbeck > Cc: atom-syntax@imc.org > Subject: RNG and examples (was: AD Review Comments and > Questions: draft-ietf-atompub-format-07) > > > Scott Hollenbeck wrote: > > > The document includes an informative RELAX NG schema and > several examples. > > What has been done to confirm that the schema is free of > errors and that all > > of the examples given in the document are valid according > to the schema? (I > > could check an XML Schema myself, but I don't have the > tools I need to check > > RELAX NG.) > > The draft is generated from an RFC2629 XML file which > contains no schema > fragments or examples. The schema fragments are generated > from the full > schema. To create the text version, the schema, fragments, > and examples > are inserted in a SAX pipeline, and xml2rfc.tcl generates the > draft from > the resulting document. Since the schema and examples are stored in > separate files, it's easy to check them with a command-line > validator. I > use James Clark's Jing[0]. > > Robert Sayre > > [0] http://www.thaiopensource.com/relaxng/jing.html > From owner-atom-syntax@mail.imc.org Tue Apr 5 13:11:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09564 for ; Tue, 5 Apr 2005 13:11:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35H4Mlr089602; Tue, 5 Apr 2005 10:04:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35H4MLa089601; Tue, 5 Apr 2005 10:04:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35H4LoA089595 for ; Tue, 5 Apr 2005 10:04:21 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 05 Apr 2005 13:04:20 -0400 id 00590082.4252C514.000057F9 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Tim Bray'" Cc: atom-syntax@imc.org Subject: RE: AD Review Comments and Questions: draft-ietf-atompub-format-07 Date: Tue, 5 Apr 2005 13:04:04 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749C990@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j35H4LoA089596 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Tim Bray [mailto:Tim.Bray@Sun.COM] > Sent: Tuesday, April 05, 2005 12:26 PM > To: Scott Hollenbeck > Cc: atom-syntax@imc.org > Subject: Re: AD Review Comments and Questions: > draft-ietf-atompub-format-07 > > > On Apr 5, 2005, at 8:39 AM, Scott Hollenbeck wrote: [snip] > > Sections 1.1, 1.2: RFC 3688/BCP 81 describes IETF practice > for naming > > XML > > namespaces. Why are namespace URIs (such as http://purl.org) that > > don't > > conform to this practice being used? > > Our plan, as we discussed with you & Ted. last year, is to use a W3C > namespace. The current value is a placeholder. Should we > note this in > -08? There needs to be both text explaining why IETF practice isn't being used and there needs to be an identified URI. We don't need the URI *right now*, but I want it in the document BEFORE I bring the document to the IESG for review. Explanatory text will suffice for last call purposes. [snip] > > The MIME media type registration template included in > section 7 MUST be > > submitted to the ietf-types list (ietf-types@alvestrand.no) for > > review. A > > two-week review period is standard for requests to register > new types > > in the > > standards tree. Please see the list archives [1] for > samples if help > > is > > needed in crafting a review request and please send the > request ASAP. > > Scott, what's the scheduling on that? Do we launch that right now, > independent of the rest of the document review process? Start it now. It can run concurrent with or before the last call. If you wait until after the last call starts it becomes the gating factor to having the document ready for IESG review. -Scott- From owner-atom-syntax@mail.imc.org Tue Apr 5 13:11:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09579 for ; Tue, 5 Apr 2005 13:11:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35H34OS089506; Tue, 5 Apr 2005 10:03:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35H34E1089505; Tue, 5 Apr 2005 10:03:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35H33hM089497 for ; Tue, 5 Apr 2005 10:03:03 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.8]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DIrS7-0001tf-He; Tue, 05 Apr 2005 17:02:59 +0000 Message-ID: <4252C4C3.1050508@franklinmint.fm> Date: Tue, 05 Apr 2005 13:02:59 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Hollenbeck CC: atom-syntax@imc.org Subject: Re: RNG and examples (was: AD Review Comments and Questions: draft-ietf-atompub-format-07) References: <046F43A8D79C794FA4733814869CDF0749C98F@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <046F43A8D79C794FA4733814869CDF0749C98F@dul1wnexmb01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Scott Hollenbeck wrote: > Thanks, but you didn't answer all of my question. Has someone (you?) > confirmed that the schema and examples are consistent? OK, I'm probably not the best person to check the examples. Volunteers? Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 5 13:32:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11244 for ; Tue, 5 Apr 2005 13:32:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35HOxOk091872; Tue, 5 Apr 2005 10:24:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35HOxt1091871; Tue, 5 Apr 2005 10:24:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j35HOvXv091863 for ; Tue, 5 Apr 2005 10:24:58 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 05 Apr 2005 17:24:48 -0000 Received: from p50824742.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.130.71.66] by mail.gmx.net (mp017) with SMTP; 05 Apr 2005 19:24:48 +0200 X-Authenticated: #1915285 Message-ID: <4252C9DF.2030209@gmx.de> Date: Tue, 05 Apr 2005 19:24:47 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: strange Live Bookmark display of HTML version of draft in Firefox Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, Firefox ironically displays a "Live Bookmark" icon for :-) This is caused by LINK tags such as ...whenever a title contains the string "Atom", it is mis-detected as a feed link. Guess we'll need to finish the feed discovery description and send it over to the Mozilla developers... Best regards, Julian From owner-atom-syntax@mail.imc.org Tue Apr 5 14:16:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14887 for ; Tue, 5 Apr 2005 14:16:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35I6ixJ095729; Tue, 5 Apr 2005 11:06:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35I6iA7095728; Tue, 5 Apr 2005 11:06:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35I6dSK095719; Tue, 5 Apr 2005 11:06:39 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF0749C990@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF0749C990@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Tue, 5 Apr 2005 11:06:40 -0700 To: Tim Bray , Scott Hollenbeck From: Paul Hoffman Subject: Re: AD Review Comments and Questions: draft-ietf-atompub-format-07 Cc: atom-syntax@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:26 AM -0700 4/5/05, Tim Bray wrote: >>Section 7.1: what process is the IESG supposed to use to review registration >>requests? Please see section 2 of RFC 2434/BCP 26 for mechanisms that might >>be used and please specify one in the document. > >Paul, care to take the lead on this? -Tim Nope. Scott: can you be more specific about your question? Section 7.1 seems pretty clear to me, but I'm possibly missing something. At 1:04 PM -0400 4/5/05, Scott Hollenbeck wrote: >There needs to be both text explaining why IETF practice isn't being used Good. >and there needs to be an identified URI. Bad. > We don't need the URI *right now*, >but I want it in the document BEFORE I bring the document to the IESG for >review. Explanatory text will suffice for last call purposes. Just to be clear: you are asking us to get the final URI for the namespace *before* the IESG has approved of the document. That means that it is really, really likely that some implementers will write and deploy code based on the draft that is going to the IESG, not waiting to see if the IESG demands changes for the wire protocol or the MUSTs and SHOULDs. Do you really want that (he asks pejoratively)? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Apr 5 14:31:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16299 for ; Tue, 5 Apr 2005 14:31:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35IPLfe097065; Tue, 5 Apr 2005 11:25:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35IPKDR097064; Tue, 5 Apr 2005 11:25:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35IPJIa097050; Tue, 5 Apr 2005 11:25:20 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 05 Apr 2005 14:25:19 -0400 id 00590082.4252D80F.00006DBC Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Paul Hoffman'" , "'Tim Bray'" Cc: atom-syntax@imc.org Subject: RE: AD Review Comments and Questions: draft-ietf-atompub-format-07 Date: Tue, 5 Apr 2005 14:25:03 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749C994@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j35IPKIa097051 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Paul Hoffman [mailto:phoffman@imc.org] > Sent: Tuesday, April 05, 2005 2:07 PM > To: Tim Bray; Scott Hollenbeck > Cc: atom-syntax@imc.org > Subject: Re: AD Review Comments and Questions: > draft-ietf-atompub-format-07 > > > At 9:26 AM -0700 4/5/05, Tim Bray wrote: > >>Section 7.1: what process is the IESG supposed to use to > review registration > >>requests? Please see section 2 of RFC 2434/BCP 26 for > mechanisms that might > >>be used and please specify one in the document. > > > >Paul, care to take the lead on this? -Tim > > Nope. Scott: can you be more specific about your question? Section > 7.1 seems pretty clear to me, but I'm possibly missing something. As described in 2434, "IESG Approval", "though the IESG has discretion to request documents or other supporting materials on a case-by-case basis". I'd really like to see some guidance in the document to describe what the IESG should look for. We're not atom experts, so it's going to be hard to determine what we should and shouldn't approve. Another paragraph will help future IESGs understand what they need to consider when reviewing requests. > At 1:04 PM -0400 4/5/05, Scott Hollenbeck wrote: > >There needs to be both text explaining why IETF practice > isn't being used > > Good. > > >and there needs to be an identified URI. > > Bad. > > > We don't need the URI *right now*, > >but I want it in the document BEFORE I bring the document to > the IESG for > >review. Explanatory text will suffice for last call purposes. > > Just to be clear: you are asking us to get the final URI for the > namespace *before* the IESG has approved of the document. That means > that it is really, really likely that some implementers will write > and deploy code based on the draft that is going to the IESG, not > waiting to see if the IESG demands changes for the wire protocol or > the MUSTs and SHOULDs. > > Do you really want that (he asks pejoratively)? Hmm. Part of the problem is that there is no "normal" editing opportunity once the document is in the hands of the IESG. The editors can make changes as a result of IESG review, or in auth48, but those changes are supposed to be directed. Auth48 changes are supposed to be editorial only. This is clearly a normative situation. The other part of the problem is that you're asking the IESG to review a specification that is incomplete without that little detail, and what's in there now looks very obviously non-standard. If you want to pursue a course of action that is similar to what was done with the IDN prefix [1] you're going to have to be a bit more clear about why the spec is incomplete. I'm OK with that, but please add text to the document to explain what needs to be done, who will do it, and when it needs to be done. Include a note that says "this paragraph to be removed by the RFC Editor" if appropriate. If this all means that the URI will be provided to the RFC Editor when they ask for it to finish the document, fine -- just say so. -Scott- [1] I'll let Paul explain this reference if anyone asks. From owner-atom-syntax@mail.imc.org Tue Apr 5 14:44:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17498 for ; Tue, 5 Apr 2005 14:44:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35IcZS8098411; Tue, 5 Apr 2005 11:38:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35IcZfQ098410; Tue, 5 Apr 2005 11:38:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35IcWht098400; Tue, 5 Apr 2005 11:38:33 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF0749C994@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF0749C994@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Tue, 5 Apr 2005 11:38:34 -0700 To: "Scott Hollenbeck" , "'Tim Bray'" From: Paul Hoffman Subject: RE: AD Review Comments and Questions: draft-ietf-atompub-format-07 Cc: atom-syntax@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:25 PM -0400 4/5/05, Scott Hollenbeck wrote: >As described in 2434, "IESG Approval", "though the IESG has discretion to >request documents or other supporting materials on a case-by-case basis". Right. >I'd really like to see some guidance in the document to describe what the >IESG should look for. We're not atom experts, so it's going to be hard to >determine what we should and shouldn't approve. Another paragraph will help >future IESGs understand what they need to consider when reviewing requests. Sounds reasonable. (I was erring on the side of not micro-managing the IESG.) Rob/Mark: please take a shot at some guidance for them. > >> At 1:04 PM -0400 4/5/05, Scott Hollenbeck wrote: >> >There needs to be both text explaining why IETF practice >> isn't being used >> >> Good. >> >> >and there needs to be an identified URI. >> >> Bad. >> >> > We don't need the URI *right now*, >> >but I want it in the document BEFORE I bring the document to >> the IESG for >> >review. Explanatory text will suffice for last call purposes. >> >> Just to be clear: you are asking us to get the final URI for the >> namespace *before* the IESG has approved of the document. That means >> that it is really, really likely that some implementers will write >> and deploy code based on the draft that is going to the IESG, not >> waiting to see if the IESG demands changes for the wire protocol or >> the MUSTs and SHOULDs. >> >> Do you really want that (he asks pejoratively)? > >Hmm. Part of the problem is that there is no "normal" editing opportunity >once the document is in the hands of the IESG. The editors can make changes >as a result of IESG review, or in auth48, but those changes are supposed to >be directed. Auth48 changes are supposed to be editorial only. This is >clearly a normative situation. Correct. I was assuming that, once everything else got approved, you would put a DISCUSS vote on the document because of the lack of final namespace. We then ask the W3C for it, get it, tell you, and make the change to the n+1 version of the document (along with the editorial comments that often come out of an IESG review). Does that sound doable? >The other part of the problem is that you're asking the IESG to review a >specification that is incomplete without that little detail, and what's in >there now looks very obviously non-standard. If you want to pursue a course >of action that is similar to what was done with the IDN prefix [1] you're >going to have to be a bit more clear about why the spec is incomplete. I'm fine with that. And, yes, I was modelling this process after than one. > I'm >OK with that, but please add text to the document to explain what needs to >be done, who will do it, and when it needs to be done. Include a note that >says "this paragraph to be removed by the RFC Editor" if appropriate. If >this all means that the URI will be provided to the RFC Editor when they ask >for it to finish the document, fine -- just say so. My preference is that the namespace be minted and included between the time that all other issues are cleared and when it is sent to the RFC Editor. In retrospect, we could have done that for the IDN spec as well. Does that work for you? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Apr 5 14:53:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18189 for ; Tue, 5 Apr 2005 14:53:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35IimiB098832; Tue, 5 Apr 2005 11:44:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35IimVi098831; Tue, 5 Apr 2005 11:44:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35IilVx098818; Tue, 5 Apr 2005 11:44:47 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 05 Apr 2005 14:44:46 -0400 id 00590082.4252DC9E.000070D1 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Paul Hoffman'" , "'Tim Bray'" Cc: atom-syntax@imc.org Subject: RE: AD Review Comments and Questions: draft-ietf-atompub-format-07 Date: Tue, 5 Apr 2005 14:44:30 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749C998@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Correct. I was assuming that, once everything else got approved, you > would put a DISCUSS vote on the document because of the lack of final > namespace. We then ask the W3C for it, get it, tell you, and make the > change to the n+1 version of the document (along with the editorial > comments that often come out of an IESG review). Does that sound > doable? Yes, we can do it this way. Just please add some text so that so that IESG reviewers understand that this is a known issue that we have a plan to address. -Scott- From owner-atom-syntax@mail.imc.org Tue Apr 5 15:53:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01807 for ; Tue, 5 Apr 2005 15:53:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35JjFV1004447; Tue, 5 Apr 2005 12:45:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35JjEqZ004446; Tue, 5 Apr 2005 12:45:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j35JjDFQ004434 for ; Tue, 5 Apr 2005 12:45:14 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 05 Apr 2005 19:45:06 -0000 Received: from pD9E625FD.dip.t-dialin.net (EHLO [192.168.0.2]) [217.230.37.253] by mail.gmx.net (mp001) with SMTP; 05 Apr 2005 21:45:06 +0200 X-Authenticated: #1915285 Message-ID: <4252EAB9.6040500@gmx.de> Date: Tue, 05 Apr 2005 21:44:57 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: updated issues list for draft 07 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, I just updated my issues list based on the current draft (that is, I didn't yet have time to scan for potential new issues). Most of the issues are editorial, but two of them IMHO really need to be addressed before the draft can be submitted (05-C05 and 05-E12). Also, the embedded RNC grammar now works for me with the standard Jing validator from James Clark's web site. Thanks! Best regards, Julian -- 05-C05, 4.15.3 processing model -06: "If the value of "type" ends with "+xml" or "/xml", the content of atom:content may include child elements, and SHOULD be suitable for handling by software that knows the indicated media type. If the "src" attribute is not provided, this would normally mean that the "atom:content" element would contain a single child element which would serve as the root element of the XML document of the indicated type." The statement about the "src" attribute seems to be unnecessary given the SHOULD-level requirement to have local content (thus no "src" attribute). "If the value of "type" begins with "text/" the content of atom:content MUST NOT contain child elements." See 4.15.2: so is this a SHOULD or a MUST? Update -06: I'm still confused by the text. For instance: - is it intentional that 4.1.3.3 says ``If the value of "type" ends with "+xml" or "/xml"'', while 4.1.3.2 used ``If the value of type begins with "text/" or ends with "+xml"''? - also, if content for +xml SHOULD be local (4.1.3.2), why does 4.1.3.3. point 4, make statements about situations where it comes with @src attribute? Maybe it's not a SHOULD requirement after all? 05-E02, Notational Conventions I think this should come with the following URL: Update -06: I think it would be good if all W3C references came with URLs. 05-E05, 3.2.2 atom:uri "The content of atom:uri in a Person construct MUST be a URI reference [RFC2396bis]." 06: Directly point to RFC3986's section (here: 4.1). Update -06: I still think that spelling out the section number will make it easier to actually locate the definition. 05-E06, 3.2.3 atom:email http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.2.3 "Its content MUST be an e-mail address [RFC2822]." Again, please refer directly to the definition. In this case, it seems to be section 3.4.1 (addr-spec production). 05-E08, 4.6.2 rel attribute 06: "...same name registered within the IANA Registry of Link Relations Section 9, and..." Put the section reference into brackets. 05-E12, 11 references 06: Here's a producedural question: if we have normative references to the protocol and the feed discovery document, the spec won't get published until those are done, too. Is everybody aware of that? Update -06: we still have a normative reference to the feed discovery spec, which, according to , has expired. If this reference is expected to stay in, we'll have to actually finish that spec as well :-) 06-C01, 3.1.1 "type" Attribute This has been mentioned before...: as far as I can tell, it's far easier for recipients to process "xhtml" compared to "html" (no tag-soup parser needed), thus *any* kind of change that encourages "xhtml" would be appreciated. Update -07: I acknowledge that the WG is unable/unwilling to look at this topic again after att the discussions we had about it earlier in. I'll leave it here inside my issues list anyway so that my disagreement is at least recorded :-) From owner-atom-syntax@mail.imc.org Tue Apr 5 16:37:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14238 for ; Tue, 5 Apr 2005 16:37:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35KT09n008347; Tue, 5 Apr 2005 13:29:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35KT0qG008346; Tue, 5 Apr 2005 13:29:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) by above.proper.com (8.12.11/8.12.9) with SMTP id j35KSvAh008336 for ; Tue, 5 Apr 2005 13:28:58 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 60189 messnum 280386 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 5 Apr 2005 20:28:51 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail03.svc.cra.dublin.eircom.net (qp 60189) with SMTP; 5 Apr 2005 20:28:51 -0000 Message-ID: <4252F500.6020600@dehora.net> Date: Tue, 05 Apr 2005 21:28:48 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Scott Hollenbeck , atom-syntax@imc.org Subject: Re: RNG and examples (was: AD Review Comments and Questions: draft-ietf-atompub-format-07) References: <046F43A8D79C794FA4733814869CDF0749C98F@dul1wnexmb01.vcorp.ad.vrsn.com> <4252C4C3.1050508@franklinmint.fm> In-Reply-To: <4252C4C3.1050508@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > Scott Hollenbeck wrote: > >> Thanks, but you didn't answer all of my question. Has someone (you?) >> confirmed that the schema and examples are consistent? > > > OK, I'm probably not the best person to check the examples. Volunteers? Me. Will be back to you in 24h. cheers Bill From owner-atom-syntax@mail.imc.org Tue Apr 5 17:46:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21144 for ; Tue, 5 Apr 2005 17:46:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35Lb1dt017415; Tue, 5 Apr 2005 14:37:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35Lb1pw017414; Tue, 5 Apr 2005 14:37:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35Lb0Wc017406 for ; Tue, 5 Apr 2005 14:37:00 -0700 (PDT) (envelope-from philringnalda@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so3766492wri for ; Tue, 05 Apr 2005 14:36: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:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=aYVzqXK/4SKRaHGYs7vXFCpbbdf6Ng6iXCQQwS2+F0CcANKYYFbQQ3ZTJevgyhpfJ7CJPQyHVbOAn/zMk+w92sDYnTam6eFmQQGiK7Hd5dQ6H+Vt93KN8Fnzd2qor15ArmMG8LlBA/IoiLObvzODc2YKgcs2yBpwlEyJ5Tgf6So= Received: by 10.54.2.38 with SMTP id 38mr222491wrb; Tue, 05 Apr 2005 14:36:54 -0700 (PDT) Received: from ?12.45.57.193? ([12.45.57.193]) by mx.gmail.com with ESMTP id 43sm1392719wri.2005.04.05.14.36.53; Tue, 05 Apr 2005 14:36:54 -0700 (PDT) Message-ID: <425304DA.5040301@gmail.com> Date: Tue, 05 Apr 2005 14:36:26 -0700 From: Phil Ringnalda User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: strange Live Bookmark display of HTML version of draft in Firefox References: <4252C9DF.2030209@gmx.de> In-Reply-To: <4252C9DF.2030209@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > Firefox ironically displays a "Live Bookmark" icon for > :-) https://bugzilla.mozilla.org/show_bug.cgi?id=257247 I've just had a hard time pushing for draconian autodiscovery, since it's vastly easier to find broken attempts at autodiscovery links which we would still like to subscribe to than it is to find non-feeds that trigger the current lax code. Phil Ringnalda From owner-atom-syntax@mail.imc.org Tue Apr 5 18:00:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22378 for ; Tue, 5 Apr 2005 18:00:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35LrZ3t018674; Tue, 5 Apr 2005 14:53:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j35LrZix018673; Tue, 5 Apr 2005 14:53:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j35LrZDA018659; Tue, 5 Apr 2005 14:53:35 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.8]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DIvzG-0005ZV-8s; Tue, 05 Apr 2005 21:53:30 +0000 Message-ID: <425308D9.4020207@franklinmint.fm> Date: Tue, 05 Apr 2005 17:53:29 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax , Paul Hoffman / IMC , Tim Bray Subject: summary of editors' action items ...so far Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anything to add? Julian Reschke wrote: > > 05-C05, 4.15.3 processing model Update -06: I'm still confused by the > text. For instance... I agree that this section is gnarly. The editors will attempt to clarify that section without making any normative changes, and will check with the WG to verify that no normative changes have been unintentionally introduced. > 06-C01, 3.1.1 "type" Attribute thus *any* kind of change that > encourages "xhtml" would be appreciated. While there is no consensus in favor of changing the document to 'encourage' XHTML, more than one person has questioned the use of XHTML-Basic. I don't remember where this decision was made (Sam?). While I disagree that XHTML has a definite advantage over HTML, I am concerned that this choice will portray XHTML as somehow less capable, since the HTML section cites the more general HTML 4.01. Graham wrote: > A quick bit of rewording would help. Currently it basically says "The > type attribute may have the values..." three times with three > different rules. Changing it to "On the summary element, the type > atrribute may have the values..." stops the spec being apparently > self-contradicting. The editors erred in failing to incorporate this suggestion in -07. We'll get it this time. Scott Hollenbeck wrote: > Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt > instead of RFC 2234 and confirm that everything that was valid before > is still valid. The IESG approved this document as a Draft Standard > last week. Will do. > Section 4: RFC 2045 is referenced. 2045 is on its way to being > obsoleted by draft-freed-mime-p4 (in the RFC Editor queue) and > draft-freed-media-type-reg (in last call). Can the more recent > documents be referenced instead of 2045? I think so. Will do. Tim Bray wrote: > We do currently say that the schema is non-normative; having said > that, a statement that there is no DTD and no validity requirement > couldn't hurt. Will add text to this effect. Paul Hoffman wrote: > >> I'd really like to see some guidance in the document to describe >> what the IESG should look for. We're not atom experts, so it's >> going to be hard to determine what we should and shouldn't approve. >> Another paragraph will help future IESGs understand what they need >> to consider when reviewing requests. > > > Sounds reasonable. (I was erring on the side of not micro-managing > the IESG.) Rob/Mark: please take a shot at some guidance for them. Will do. Scott Hollenbeck wrote w.r.t. the namespace: > Yes, we can do it this way. Just please add some text so that so that IESG > reviewers understand that this is a known issue that we have a plan to > address. OK, will do. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 5 20:11:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03688 for ; Tue, 5 Apr 2005 20:11:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3601UOP030369; Tue, 5 Apr 2005 17:01:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3601Uwc030368; Tue, 5 Apr 2005 17:01:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3601TID030362 for ; Tue, 5 Apr 2005 17:01:29 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3601TRr024405 for ; Tue, 5 Apr 2005 18:01:29 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEI0076X02GH5@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 05 Apr 2005 18:01:29 -0600 (MDT) Received: from [192.168.102.100] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEI00AYL02HOI@mail.sun.net> for atom-syntax@imc.org; Tue, 05 Apr 2005 18:01:30 -0600 (MDT) Date: Tue, 05 Apr 2005 17:01:56 -0700 From: Tim Bray Subject: Sample -07 feed To: "Atom-Syntax Syntax'" Message-id: <7cab4cbb7fd4c5f8b2ef79446590023a@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT http://www.tbray.org/ongoing/ongoing.atom Norm's RNC says it's OK. -Tim From owner-atom-syntax@mail.imc.org Wed Apr 6 05:33:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19361 for ; Wed, 6 Apr 2005 05:33:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j369S5NZ054139; Wed, 6 Apr 2005 02:28:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j369S5kp054137; Wed, 6 Apr 2005 02:28:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j369S4e8054129 for ; Wed, 6 Apr 2005 02:28:04 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 22463 invoked by uid 17064); 6 Apr 2005 09:28:03 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.15.50]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 6 Apr 2005 09:28:03 -0000 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Atom Syntax From: Henry Story Subject: next, previous Date: Wed, 6 Apr 2005 11:28:01 +0200 X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Are the "next" and "previous" links that we thought may be attachable to the feed really too controversial to get into the final atom spec? They would be really useful to archive feeds. Henry Story From owner-atom-syntax@mail.imc.org Wed Apr 6 08:31:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06098 for ; Wed, 6 Apr 2005 08:31:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j36CMJK8011543; Wed, 6 Apr 2005 05:22:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j36CMJFo011542; Wed, 6 Apr 2005 05:22:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j36CMI0O011531 for ; Wed, 6 Apr 2005 05:22:18 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 06 Apr 2005 08:22:18 -0400 id 00590092.4253D47A.00005604 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: atom-syntax@imc.org Subject: FW: XML Directorate Reviewer Comments Date: Wed, 6 Apr 2005 08:22:00 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749C99D@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Here are some more -07 review comments from one member of the XML Directorate. We already know about #1. It's OK to ask questions about the reviewer's questions, just please cc him directly if you wish to start a dialog. -Scott- -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Tuesday, April 05, 2005 6:25 PM To: Scott Hollenbeck Cc: xml-dir@ietf.org Subject: Re: [xml-dir] FW: draft-ietf-atompub-format-07.txt is ready for IETF last call A very good document overall. I found just a few items, all minor. 1) Section 1.2. The "atom" prefix uses a namespace URI not under change control of the IETF. See BCP 81. Also, purl.org is not listed in 2606. 2) Section 4.1.3.3 Item 2 The text: for example, "
" as "<br>". Is this right? Should it be: for example, "
" as "<br>". Also, should the "must" in "The HTML markup must be escaped" be a MUST? Should rule 2 have the same note regarding the
element as rule 3? What happens if the type is html and the content is all within <div> .... </div> ? 3) Section 4.2.4 Is the "atom:copyright" also meant to convey an applicable distribution license? -andy From owner-atom-syntax@mail.imc.org Wed Apr 6 11:44:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28007 for ; Wed, 6 Apr 2005 11:44:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j36FaIUB034336; Wed, 6 Apr 2005 08:36:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j36FaIwX034335; Wed, 6 Apr 2005 08:36:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j36FaFIi034316 for ; Wed, 6 Apr 2005 08:36:17 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 6 Apr 2005 08:36:11 -0700 To: Atom Syntax From: Paul Hoffman Subject: Re: next, previous Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:28 AM +0200 4/6/05, Henry Story wrote: >Are the "next" and "previous" links that we thought may be >attachable to the feed >really too controversial to get into the final atom spec? It doesn't matter whether or not they are "too controversial"; the spec is frozen for significant technical changes. Unless, of course, the WG decides we really do want to open it all up again an take another probably four months of deciding what else we want to add and change. We can do that by amending our charter. So far, I have not heard consensus going towards that, but I could be wrong. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Apr 6 11:52:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28656 for ; Wed, 6 Apr 2005 11:52:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j36FjBK3034911; Wed, 6 Apr 2005 08:45:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j36FjBmY034910; Wed, 6 Apr 2005 08:45:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail10.svc.cra.dublin.eircom.net (mail10.svc.cra.dublin.eircom.net [159.134.118.26]) by above.proper.com (8.12.11/8.12.9) with SMTP id j36FjASB034896 for ; Wed, 6 Apr 2005 08:45:10 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 91057 messnum 6690261 invoked from network[213.94.211.166/dev2.mcpps.com]); 6 Apr 2005 15:45:04 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail10.svc.cra.dublin.eircom.net (qp 91057) with SMTP; 6 Apr 2005 15:45:04 -0000 Message-ID: <425403FD.3060300@dehora.net> Date: Wed, 06 Apr 2005 16:45:01 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Atom Syntax Subject: Re: next, previous References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > > At 11:28 AM +0200 4/6/05, Henry Story wrote: > >> Are the "next" and "previous" links that we thought may be attachable >> to the feed >> really too controversial to get into the final atom spec? > > > It doesn't matter whether or not they are "too controversial"; the spec > is frozen for significant technical changes. > > Unless, of course, the WG decides we really do want to open it all up > again an take another probably four months of deciding what else we want > to add and change. We can do that by amending our charter. So far, I > have not heard consensus going towards that, but I could be wrong. Henry, Paul is right; also adding riders to the spec at this stage is potentially harmful because the review cycle is less substantial. My best suggestion is to write an I-D that describe the link extensions; that will be probably get more eyeballs/traction than a Pace at this stage. cheers Bill From owner-atom-syntax@mail.imc.org Wed Apr 6 16:42:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02367 for ; Wed, 6 Apr 2005 16:42:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j36KOepd057109; Wed, 6 Apr 2005 13:24:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j36KOe7R057108; Wed, 6 Apr 2005 13:24:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j36KOcFQ057100 for ; Wed, 6 Apr 2005 13:24:40 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJH4k-00064G-HC for atom-syntax@imc.org; Wed, 06 Apr 2005 20:24:34 +0000 Message-ID: <4254457F.20405@franklinmint.fm> Date: Wed, 06 Apr 2005 16:24:31 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: PaceCoConstraintsAreBad Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceCoConstraintsAreBad Abstract ------------------------ Require atom:id, atom:title, atom:updated, atom:author. That's it. Status ------------------------ Open Rationale ------------------------ The spec delivers value when it can make an element mandatory. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 6 20:23:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25273 for ; Wed, 6 Apr 2005 20:23:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j370DhaC071387; Wed, 6 Apr 2005 17:13:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j370DhKg071385; Wed, 6 Apr 2005 17:13:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j370DgN9071377 for ; Wed, 6 Apr 2005 17:13:42 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.168.14]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id C6D0CA32ED; Wed, 6 Apr 2005 20:13:40 -0400 (EDT) In-Reply-To: References: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5b29c515110e3fbee7186e18a47661c0@mnot.net> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org, Scott Hollenbeck X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: AD Review Comments and Questions: draft-ietf-atompub-format-07 Date: Wed, 6 Apr 2005 17:13:38 -0700 To: Tim Bray X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 5, 2005, at 9:26 AM, Tim Bray wrote: >> Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt >> instead >> of RFC 2234 and confirm that everything that was valid before is still >> valid. The IESG approved this document as a Draft Standard last week. > > Rob/Mark? Hmm. As far as I can tell, the *only* place where we actually define a rule is 4.2.9.2, and that's just combining two rules by reference. I wonder if we can save complexity here (and remove one normative reference) by just doing this in prose; the text is currently: [[[ ABNF for the "rel" attribute: rel_attribute = isegment-nz-nc / IRI The value of "rel" MUST be string that is non-empty, does not contain any colon (":") characters, and matches the "isegment-nz-nc" or "IRI" ABNF forms in [RFC3987]. ]]] So it seems like the ABNF is extraneous here, and if we dropped it, we could also drop the reference. (Just a suggestion, I'm also happy to change the reference.) Also, looking into this popped up a few more small editorial issues; - 3.2.3 mentions BNF in relation to 2822, but RFC2822 uses ABNF - 4.2.9.2 nominates rules by surrounding them with "quotation marks"; they are bare elsewhere in the spec >> Section 2 describes a requirement for well-formedness, but it doesn't >> mention validity. I suspect that validity isn't a requirement given >> that >> the RELAX NG schema is informative, but it would be better if a >> specific >> statement were included to note that validity is not a requirement. > > Hmm, I would say that validity isn't a requirement because the > syntactic constraints are (we think) fully given in the text. The > group consciously decided not to make the schema normative, for that > reason. We do currently say that the schema is non-normative; having > said that, a statement that there is no DTD and no validity > requirement couldn't hurt. Rob/Mark? Suggest adding the following after "Atom Documents MUST be well-formed XML."; [[[This specification does not define a DTD for Atom Documents, and hence does not require them to be valid (in the sense used by XML).]]] >> Section 4: RFC 2045 is referenced. 2045 is on its way to being >> obsoleted by >> draft-freed-mime-p4 (in the RFC Editor queue) and >> draft-freed-media-type-reg >> (in last call). Can the more recent documents be referenced instead >> of >> 2045? > > Rob/Mark? I think all of the references would go to draft-freed-mime-p4. As an aside -- it appears we may reference a few documents that are in the RFC editor queue, or about to be there. It might be good to set expectations within the WG as to what that means for our publication schedule. >> Section 7.1: what process is the IESG supposed to use to review >> registration >> requests? Please see section 2 of RFC 2434/BCP 26 for mechanisms >> that might >> be used and please specify one in the document. Hmm. Looking over this, I wonder why IESG approval was the path chosen, given that URIs can also be used. It seems like the natural bar for getting something into the registry would be IETF consensus; can someone comment as to why this was chosen (I didn't participate in the discussions surrounding this registry)? If we remain on an IESG approval path, such text would probably look something like; "Registered link relations SHOULD be widely implemented, since they effectively serve as shortcuts for URIs; as such, proposals need to demonstrate that there is community value in minting such a shortcut." Also, it may be good to replace the list of suggested topics with a registration template, to get more uniformity and make IANA's life easier (sorry I didn't notice this earlier). Finally, has someone doubled-checked with IANA that the "http://www.iana.org/assignments/relation/" URI is available and appropriate? -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Apr 6 20:45:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27076 for ; Wed, 6 Apr 2005 20:45:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j370alNE073041; Wed, 6 Apr 2005 17:36:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j370alLJ073040; Wed, 6 Apr 2005 17:36:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j370afY0073021; Wed, 6 Apr 2005 17:36:41 -0700 (PDT) (envelope-from tbray@textuality.com) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j370afXi028676; Wed, 6 Apr 2005 18:36:41 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEJ009UPWD4B5@edgemail1.Central.Sun.COM>; Wed, 06 Apr 2005 18:36:40 -0600 (MDT) Received: from [192.168.102.100] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEJ0096HWD38J@mail.sun.net>; Wed, 06 Apr 2005 18:36:40 -0600 (MDT) Date: Wed, 06 Apr 2005 17:37:08 -0700 From: Tim Bray Subject: Re: summary of editors' action items ...so far In-reply-to: <425308D9.4020207@franklinmint.fm> To: mint@franklinmint.fm Cc: Atom Syntax , Paul Hoffman / IMC Message-id: <85dd5d1f7301558ecb2fec4ace17a0f5@textuality.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <425308D9.4020207@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 5, 2005, at 2:53 PM, Robert Sayre wrote: > Anything to add? No, I think Rob's got it. Sooner is better. Who's going to take care of submitting the MIME type registration? A volunteer would be welcome. -Tim > > Julian Reschke wrote: >> 05-C05, 4.15.3 processing model Update -06: I'm still confused by the >> text. For instance... > > I agree that this section is gnarly. The editors will attempt to > clarify > that section without making any normative changes, and will check with > the WG to verify that no normative changes have been unintentionally > introduced. > >> 06-C01, 3.1.1 "type" Attribute thus *any* kind of change that >> encourages "xhtml" would be appreciated. > > While there is no consensus in favor of changing the document to > 'encourage' XHTML, more than one person has questioned the use of > XHTML-Basic. I don't remember where this decision was made (Sam?). > While I disagree that XHTML has a definite advantage over HTML, I am > concerned that this choice will portray XHTML as somehow less capable, > since the HTML section cites the more general HTML 4.01. > > Graham wrote: >> A quick bit of rewording would help. Currently it basically says "The >> type attribute may have the values..." three times with three >> different rules. Changing it to "On the summary element, the type >> atrribute may have the values..." stops the spec being apparently >> self-contradicting. > > The editors erred in failing to incorporate this suggestion in -07. > We'll get it this time. > > Scott Hollenbeck wrote: >> Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt >> instead of RFC 2234 and confirm that everything that was valid before >> is still valid. The IESG approved this document as a Draft Standard >> last week. > > Will do. > >> Section 4: RFC 2045 is referenced. 2045 is on its way to being >> obsoleted by draft-freed-mime-p4 (in the RFC Editor queue) and >> draft-freed-media-type-reg (in last call). Can the more recent >> documents be referenced instead of 2045? > > I think so. Will do. > > Tim Bray wrote: >> We do currently say that the schema is non-normative; having said >> that, a statement that there is no DTD and no validity requirement >> couldn't hurt. > > Will add text to this effect. > > Paul Hoffman wrote: >>> I'd really like to see some guidance in the document to describe >>> what the IESG should look for. We're not atom experts, so it's >>> going to be hard to determine what we should and shouldn't approve. >>> Another paragraph will help future IESGs understand what they need >>> to consider when reviewing requests. >> Sounds reasonable. (I was erring on the side of not micro-managing >> the IESG.) Rob/Mark: please take a shot at some guidance for them. > > Will do. > > Scott Hollenbeck wrote w.r.t. the namespace: >> Yes, we can do it this way. Just please add some text so that so >> that IESG >> reviewers understand that this is a known issue that we have a plan to >> address. > > OK, will do. > > Robert Sayre > - Tim Bray, Director of Web Technologies, Sun Microsystems +1-877-305-0889 Sun ext. 60561 http://www.tbray.org/ongoing/ AIM: MarkupPedant From owner-atom-syntax@mail.imc.org Wed Apr 6 21:24:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00893 for ; Wed, 6 Apr 2005 21:24:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j371GQI2075773; Wed, 6 Apr 2005 18:16:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j371GQ7H075772; Wed, 6 Apr 2005 18:16:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j371GPXp075743; Wed, 6 Apr 2005 18:16:25 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 79977A32D9; Wed, 6 Apr 2005 21:16:23 -0400 (EDT) In-Reply-To: <85dd5d1f7301558ecb2fec4ace17a0f5@textuality.com> References: <425308D9.4020207@franklinmint.fm> <85dd5d1f7301558ecb2fec4ace17a0f5@textuality.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4ff3f927275a3d2bc1c91ccdd331c446@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , mint@franklinmint.fm, Paul Hoffman / IMC X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: summary of editors' action items ...so far Date: Wed, 6 Apr 2005 18:16:21 -0700 To: Tim Bray X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I can do that later tonight. On Apr 6, 2005, at 5:37 PM, Tim Bray wrote: > > On Apr 5, 2005, at 2:53 PM, Robert Sayre wrote: > >> Anything to add? > > No, I think Rob's got it. Sooner is better. > > Who's going to take care of submitting the MIME type registration? A > volunteer would be welcome. -Tim > >> >> Julian Reschke wrote: >>> 05-C05, 4.15.3 processing model Update -06: I'm still confused by the >>> text. For instance... >> >> I agree that this section is gnarly. The editors will attempt to >> clarify >> that section without making any normative changes, and will check >> with the WG to verify that no normative changes have been >> unintentionally introduced. >> >>> 06-C01, 3.1.1 "type" Attribute thus *any* kind of change that >>> encourages "xhtml" would be appreciated. >> >> While there is no consensus in favor of changing the document to >> 'encourage' XHTML, more than one person has questioned the use of >> XHTML-Basic. I don't remember where this decision was made (Sam?). >> While I disagree that XHTML has a definite advantage over HTML, I am >> concerned that this choice will portray XHTML as somehow less >> capable, since the HTML section cites the more general HTML 4.01. >> >> Graham wrote: >>> A quick bit of rewording would help. Currently it basically says "The >>> type attribute may have the values..." three times with three >>> different rules. Changing it to "On the summary element, the type >>> atrribute may have the values..." stops the spec being apparently >>> self-contradicting. >> >> The editors erred in failing to incorporate this suggestion in -07. >> We'll get it this time. >> >> Scott Hollenbeck wrote: >>> Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt >>> instead of RFC 2234 and confirm that everything that was valid before >>> is still valid. The IESG approved this document as a Draft Standard >>> last week. >> >> Will do. >> >>> Section 4: RFC 2045 is referenced. 2045 is on its way to being >>> obsoleted by draft-freed-mime-p4 (in the RFC Editor queue) and >>> draft-freed-media-type-reg (in last call). Can the more recent >>> documents be referenced instead of 2045? >> >> I think so. Will do. >> >> Tim Bray wrote: >>> We do currently say that the schema is non-normative; having said >>> that, a statement that there is no DTD and no validity requirement >>> couldn't hurt. >> >> Will add text to this effect. >> >> Paul Hoffman wrote: >>>> I'd really like to see some guidance in the document to describe >>>> what the IESG should look for. We're not atom experts, so it's >>>> going to be hard to determine what we should and shouldn't approve. >>>> Another paragraph will help future IESGs understand what they need >>>> to consider when reviewing requests. >>> Sounds reasonable. (I was erring on the side of not micro-managing >>> the IESG.) Rob/Mark: please take a shot at some guidance for them. >> >> Will do. >> >> Scott Hollenbeck wrote w.r.t. the namespace: >>> Yes, we can do it this way. Just please add some text so that so >>> that IESG >>> reviewers understand that this is a known issue that we have a plan >>> to >>> address. >> >> OK, will do. >> >> Robert Sayre >> > - Tim Bray, Director of Web Technologies, Sun Microsystems > +1-877-305-0889 Sun ext. 60561 > http://www.tbray.org/ongoing/ AIM: MarkupPedant > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Apr 6 21:55:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02644 for ; Wed, 6 Apr 2005 21:55:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j371pHA2077911; Wed, 6 Apr 2005 18:51:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j371pHDV077910; Wed, 6 Apr 2005 18:51:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j371pHhS077897; Wed, 6 Apr 2005 18:51:17 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJMAt-0002rG-HC; Thu, 07 Apr 2005 01:51:15 +0000 Message-ID: <4254920F.8090603@franklinmint.fm> Date: Wed, 06 Apr 2005 21:51:11 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax , Paul Hoffman / IMC Subject: Re: summary of editors' action items ...so far References: <425308D9.4020207@franklinmint.fm> <85dd5d1f7301558ecb2fec4ace17a0f5@textuality.com> In-Reply-To: <85dd5d1f7301558ecb2fec4ace17a0f5@textuality.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Apr 5, 2005, at 2:53 PM, Robert Sayre wrote: > >> Anything to add? > > > No, I think Rob's got it. Sooner is better. > > Who's going to take care of submitting the MIME type registration? A > volunteer would be welcome. I'm unable to discern any consensus around the cardinality constraints brought up in various messages to the list. One thing is certain--no one has spoken up in favor of the current text. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 6 21:57:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02678 for ; Wed, 6 Apr 2005 21:57:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j371ohip077859; Wed, 6 Apr 2005 18:50:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j371ohGQ077858; Wed, 6 Apr 2005 18:50:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail10.svc.cra.dublin.eircom.net (mail10.svc.cra.dublin.eircom.net [159.134.118.26]) by above.proper.com (8.12.11/8.12.9) with SMTP id j371ogl0077851 for ; Wed, 6 Apr 2005 18:50:43 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 6968 messnum 6684030 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 7 Apr 2005 01:50:36 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail10.svc.cra.dublin.eircom.net (qp 6968) with SMTP; 7 Apr 2005 01:50:36 -0000 Message-ID: <425491E7.3020605@dehora.net> Date: Thu, 07 Apr 2005 02:50:31 +0100 From: =?windows-1252?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Obs on format-07 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi editors, Comments and observations on the 07 draft. ** RNC Schema - is valid rnc - the schema and the fragments appear to be consistent. - both examples validate according to the supplied schema - the xhtml fragments in 4.1.3.4 validate when embedded as specified. - in 6.4; simple and extension schema forbid the use of the atom namespace as the top level element in the extension. This is a very common RNG idiom and I imagine the text should reflect the constraint assuming that's the consensus of the WG. Note that it cannot generally be represented in WXS; for example, Trang will convert it to a looser xsd:any constraint. - in 6.4; extension schema allow the use of the atom namespace as child elements of the extension. I do not recall this being discussed, but personally am +1 to it. - I believe atomfeed and replace: [[[ App B Collected RELAX NG Compact Schema ]]] with: "App B RELAX NG Compact Schema" reason: not all the schema is presented in fragment form, so the title is incorrect. ** 1. Introduction p2. the last sentence requires a for-example or should be struck. reason: qualify what 'other purposes' might be. ** 1.1 Examples: Please use a namespace prefix for both or at least one of the examples. reason: 1) default namespaces are not robust (I offer requirement of xhtml:div as evidence), examples in XML formats should not propagate the practice. 2) example markup is not consistent with naming convention used to call out specified elements. Please add a element property to an entry that is not from the format (ie Dublin Core) reason: demonstrate what extensible indicates upfront. ** 2. Atom Documents p5: this paragraph can be struck without loss of meaning. reason: adds no specification value. p8: replace: [[[ Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986]. For resolution, IRIs can easily be converted to URIs. When comparing IRIs serving as atom:id values, they MUST NOT be converted to URIs. By definition, every URI is an IRI, so any URI can be used where an IRI is needed. ]]] with the following: "Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986]. By definition, every URI is an IRI, so any URI can be used where an IRI is needed. Note: 1. For purposes of resolution, IRIs MAY be converted to URIs. 2. For purposes of comparison, where IRIs act as atom:id values, they MUST NOT be converted to URIs." Also, if 'resolution' is a term taken from some spec it should be called out as such. reason: p8 does not read clearly enough to provide implementor guidance. ob: I think this indicates an implementor burden of using IRIs. I need to write conversion code differently depending on whether I'm resolving or comparing. p10: remove the following clause: [[[but may be defined by an extension to Atom.]]] reason: the caveat adds no specification value and provides questions without answers (does 'may' mean 'might' above? defined by who? etc). ** 3.1.1 The "type" Attribute replace: [[[ Note that MIME media types [RFC2045] are not acceptable values for the "type" attribute. ]]] with: "MIME media types [RFC2045] MUST NOT be used as values for the "type" attribute." reason: state the specification as specification not as a side note. ** 3.1.1.3 XHTML replace [[[ The following example assumes that the XHTML namespace has been bound to the "xh" prefix earlier in the document: ]]] with "Note: the following example is not well formed unless the XHTML namespace has been bound previously to the "xh" prefix in the document:" reason: clearly indicate what conformance prefix binding entails. ** 4.1.1 The "atom:feed" Element replace: [[[ * atom:feed elements MUST contain exactly one atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. atom:feed elements MUST NOT contain more than one atom:author element. ]]] with: "* atom:feed elements MUST contain an atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. * atom:feed elements MUST NOT contain more than one atom:author element." reason: give each spec its own bullet point. replace: [[[ * atom:feed elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same type attribute value. If a feed's atom:link element with type="alternate" resolves to an HTML document, then that document SHOULD have a autodiscovery link element [Atom-autodiscovery] that reflects back to the feed. atom:feed elements MAY contain additional atom:link elements beyond those described above. ]]] with: "* atom:feed elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" which have the same type attribute value. * If a feed's atom:link element with type="alternate" resolves to an HTML document, then that document SHOULD have a autodiscovery link element [Atom-autodiscovery] that reflects back to the feed. * atom:feed elements MAY contain additional atom:link elements with values of the rel attribute other than 'alternate' and 'self'." reason: give each spec its own bullet point. Change "that has" to "which have" as we're dealing with plurals. ** 4.1.2 The "atom:entry" Element replace: [[[ * atom:entry elements MUST contain exactly one atom:author element, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. atom:entry elements MUST NOT contain more than one atom:author element. ]]] with: "* atom:entry elements MUST contain exactly one atom:author element, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. * atom:entry elements MUST NOT contain more than one atom:author element." reason: give each spec its own bullet point. replace: [[[ * atom:entry elements that contain no child atom:content element MUST contain at least one atom:link element with a rel attribute value of "alternate". atom:entry elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same combination of type and hreflang attribute values. atom:entry elements MAY contain additional atom:link elements beyond those described above. ]]] with: "* atom:entry elements that contain no child atom:content element MUST contain at least one atom:link element with a rel attribute value of "alternate". * atom:entry elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" which have the same combination of type and hreflang attribute values. * atom:entry elements MAY contain additional atom:link elements with values of the rel attribute other than 'alternate'." reason: give each spec its own bullet point. Change "that has" to "which have" as we're dealing with plurals. ** 4.2.7 The "atom:id" Element replace: [[[ Because of the risk of confusion between IRIs that would be equivalent if dereferenced, the following normalization strategy is strongly encouraged when generating atom:id elements: ]]] with: "Because of the risk of confusion between IRIs that would be equivalent if dereferenced, the following normalization strategy SHOULD be applied when generating atom:id elements:" reason: reason: prefer operational text; strongly encouraged sounds very like a SHOULD. ** 6.4.1 Simple Extension Elements add: add to end of para "simpleExtensionElement = element * - atom:* { text }" ** 6.4.2 Structured Extension Elements "structuredExtensionElement = element * - atom:* { (attribute * { text }+, (text|anyElement)*) | (attribute * { text }*, (text?, anyElement+, (text|anyElement)*)) }" ** General ** ** references [Atom-autodiscovery] Pilgrim, M., “Atom Feed Autodiscovery”, work-in-progress, August 2004. I'm not sure Atom need be depending on this document. I probably missed that thread where we said it was ok. add to the informative references: [RELAX-NC] OASIS Technical Committee: Committee Specification 21, “RELAX NG Compact Syntax”, November 2002. fyi:http://www.oasis-open.org/committees/relax-ng/compact-20021121.html ** ABNF Drop. in 1.2, remove: [[[ Some sections of this specification are illustrated with Augmented Backus-Naur Form (ABNF), a format used to represent permissible strings in a protocol or language, as defined in [RFC2234]. ]]] in 9.1 remove: [[[ [RFC2234] Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, RFC 2234, November 1997. ]] reason: ABNF is used in one place: 4.2.9.2 The "rel" Attribute, p1 and referred to in 3.3. It's incidental enough to be dropped. ** Figures Please add figure captions for all samples, bnf and rnc fragments. If you require someone to do this, I will do it. ** Replace specification keywords in lowercase (argghh!) 2. p10, "but may be defined by" 4.1.3.2, p1 "That is to say, the content may be retrievable usingThat is to say, the content may be retrievable using", "or it may be contained within atom:content, but not both." 4.1.3.3, bullet 2 " The XHTML div MUST contain XHTML text and markup that could validly" bullet 4 "the content of atom:content may include child elements" bullet 6 "the Base64 encoding may be preceded" 4.2.9.2 p4 bullet 4 "large in size and may require special handling" 5.1, p3, "the document element must not cause an Atom Processor" 6.2 p1 "versions of this specification may add new elements" 6.3 p1 "It may be the case" - replace 'may' with 'might' here 8.1 p1 "to receiving software, which may process it." 8.2 p2 "other elements may also have negative security properties" - replace 'may' with 'might' here note: in some cases, may might be being used to indicate to indicate something is possible rather than something is permissable, I can determine that for sure in only two cases above; since may has a technical meaning, the editors should review the text and replace may with might as they see fit to avoid the idiomatic use of may as might. From owner-atom-syntax@mail.imc.org Wed Apr 6 22:14:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03716 for ; Wed, 6 Apr 2005 22:14:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3727SJF078703; Wed, 6 Apr 2005 19:07:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3727SKq078702; Wed, 6 Apr 2005 19:07:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3727RgY078696 for ; Wed, 6 Apr 2005 19:07:27 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3729Gdj002586; Wed, 6 Apr 2005 22:09:18 -0400 Message-ID: <425495D7.8080206@intertwingly.net> Date: Wed, 06 Apr 2005 22:07:19 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Atom Syntax Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> In-Reply-To: <4254457F.20405@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > http://www.intertwingly.net/wiki/pie/PaceCoConstraintsAreBad > > Abstract > ------------------------ > Require atom:id, atom:title, atom:updated, atom:author. That's it. > > Status > ------------------------ > Open > > Rationale > ------------------------ > The spec delivers value when it can make an element mandatory. co-constraints are bad. Entries without either a summary or content or even a link to where you can find the data are worse. -1 - Sam Ruby P.S. If it pleases your sense of aesthetics, merge these three elements into one mandatory element, with an attribute to specify whether the innerxml represents a summary or a content, and another optional element specifying the location. Oh, and allow multiples of this element as there are scenarios in which both summaries and content are provided. From owner-atom-syntax@mail.imc.org Wed Apr 6 22:16:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03763 for ; Wed, 6 Apr 2005 22:16:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j372AtJE078911; Wed, 6 Apr 2005 19:10:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j372AtJ7078910; Wed, 6 Apr 2005 19:10:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j372AsYr078903 for ; Wed, 6 Apr 2005 19:10:54 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJMTs-00033r-St; Thu, 07 Apr 2005 02:10:52 +0000 Message-ID: <425496A7.9030002@franklinmint.fm> Date: Wed, 06 Apr 2005 22:10:47 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Atom Syntax Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> In-Reply-To: <425495D7.8080206@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > co-constraints are bad. > > Entries without either a summary or content or even a link to where you > can find the data are worse. Does my Pace allow such a creature? Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 6 22:16:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03819 for ; Wed, 6 Apr 2005 22:16:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j372Acdf078869; Wed, 6 Apr 2005 19:10:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j372Acra078868; Wed, 6 Apr 2005 19:10:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j372AadJ078862 for ; Wed, 6 Apr 2005 19:10:36 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j372AaK2001681 for ; Wed, 6 Apr 2005 20:10:36 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEK00EH10PNOK@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 06 Apr 2005 20:10:36 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEK009EU0PN8J@mail.sun.net> for atom-syntax@imc.org; Wed, 06 Apr 2005 20:10:35 -0600 (MDT) Date: Wed, 06 Apr 2005 19:11:05 -0700 From: Tim Bray Subject: Re: Obs on format-07 In-reply-to: <425491E7.3020605@dehora.net> To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Cc: Atom Syntax Message-id: <674377e80f25f068355d1bb30bfd0779@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <425491E7.3020605@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j372AbdJ078863 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Apr 6, 2005, at 6:50 PM, Bill de hÓra wrote: > > > Hi editors, > > Comments and observations on the 07 draft. Most seem OK to me, but... > replace > [[[ > The following example assumes that the XHTML namespace has been bound > to the "xh" prefix earlier in the document: > ]]] > > with > > "Note: the following example is not well formed unless In fact, it is "well-formed" if you are using that word in the technical XML sense; the definition of well-formedness does not forbid random colon prefixing. I think this is OK left as is. The meaning is entirely unambiguous. -Tim From owner-atom-syntax@mail.imc.org Wed Apr 6 22:41:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05388 for ; Wed, 6 Apr 2005 22:41:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j372XoSD080677; Wed, 6 Apr 2005 19:33:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j372XorS080676; Wed, 6 Apr 2005 19:33:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j372XoBj080665 for ; Wed, 6 Apr 2005 19:33:50 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc12) with SMTP id <2005040702334301400f93lne>; Thu, 7 Apr 2005 02:33:43 +0000 Date: Wed, 6 Apr 2005 20:33:43 -0600 Subject: Re: Obs on format-07 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <425491E7.3020605@dehora.net> Message-Id: <75A2ED4B-A70D-11D9-A96A-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j372XoBj080671 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wednesday, April 6, 2005, at 07:50 PM, Bill de hÓra wrote: > "Note: the following example is not well formed unless the XHTML > namespace has been bound previously to the "xh" prefix in the > document:" +1 to the concept, but perhaps it could be worded a little differently, eg. 'Note: the following example is only well formed if the XHTML namespace has been bound to the "xh" prefix earlier in the document.' If we want to be more verbose to be precise, we could add something to the effect that that namespace to prefix binding is in scope at this point in the document. Reasons: 1) the first part of the sentence sounds like it's going to say that we're about to show an invalid example, and 2) "previously" (or "earlier") and "in the document" belong together. Perhaps the editors would have tweaked it, but it doesn't hurt to comment... > "* atom:feed elements MUST NOT contain more than one atom:link element > with a rel attribute value of "alternate" which have the same type > attribute value. Under atom:entry, we have: 'atom:entry elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same combination of type and hreflang attribute values.' hreflang needs to be added under feed too, right? > 4.2.9.2 The "rel" Attribute, p1 > > and referred to in 3.3. It's incidental enough to be dropped. Not sure what you're referring to here. Could you quote the text? From owner-atom-syntax@mail.imc.org Wed Apr 6 22:50:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05845 for ; Wed, 6 Apr 2005 22:50:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j372eKq8081514; Wed, 6 Apr 2005 19:40:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j372eKrF081513; Wed, 6 Apr 2005 19:40:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j372eJEq081506 for ; Wed, 6 Apr 2005 19:40:19 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j372gBlB006279; Wed, 6 Apr 2005 22:42:12 -0400 Message-ID: <42549D8D.5090708@intertwingly.net> Date: Wed, 06 Apr 2005 22:40:13 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Atom Syntax Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> In-Reply-To: <425496A7.9030002@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > Sam Ruby wrote: > >> co-constraints are bad. >> >> Entries without either a summary or content or even a link to where >> you can find the data are worse. > > Does my Pace allow such a creature? This pace dropped the requirement for an alternate link. This pace dropped the requirement for a summary when content is not present. Content remains optional. Am I misreading the Pace? The abstract seems clear enough... While I agree with your recent statement that "no one has spoken up in favor of the current text", I resonate more with Paul's recent statement[1] that: It doesn't matter whether or not they are "too controversial"; the spec is frozen for significant technical changes. Unless, of course, the WG decides we really do want to open it all up again an take another probably four months of deciding what else we want to add and change. We can do that by amending our charter. So far, I have not heard consensus going towards that, but I could be wrong. I wrote a Pace that inserted seven words and only changed one element, feeling that we might be able to come to an agreement on that. This appears to have been a tactical error as it was immediately followed by a pace that changed one word and added twenty one, affecting two elements. Now you introduce a pace that changes the definition of three elements. My order of preference: PaceFeedIdOrAlternate PaceFeedIdOrSelf Current Text PaceCoConstraintsAreBad - Sam Ruby http://www.imc.org/atom-syntax/mail-archive/msg14049.html From owner-atom-syntax@mail.imc.org Wed Apr 6 23:11:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07165 for ; Wed, 6 Apr 2005 23:11:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3734Nai082802; Wed, 6 Apr 2005 20:04:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3734Nv6082801; Wed, 6 Apr 2005 20:04:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3734MKg082794 for ; Wed, 6 Apr 2005 20:04:22 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12ld2tn.cable.mindspring.com ([69.86.139.183] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJNJc-0003ce-Dk; Thu, 07 Apr 2005 03:04:20 +0000 Message-ID: <4254A32F.1020601@franklinmint.fm> Date: Wed, 06 Apr 2005 23:04:15 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Atom Syntax Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> In-Reply-To: <42549D8D.5090708@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > This pace dropped the requirement for an alternate link. This pace > dropped the requirement for a summary when content is not present. Yes, because the WG has *never* voiced an opinion in favor of that constraint, and we fail to meet the requirements of our charter for any definition of "syndication"that takes prior art into account. > Content remains optional. The pace did not drop the requirement for a link element in the absence of content. > > Am I misreading the Pace? The abstract seems clear enough... > > While I agree with your recent statement that "no one has spoken up in > favor of the current text", I resonate more with Paul's recent > statement[1] that: > > It doesn't matter whether or not they are "too controversial"; the > spec is frozen for significant technical changes. > > Unless, of course, the WG decides we really do want to open it all up > again an take another probably four months of deciding what else we > want to add and change. We can do that by amending our charter. So > far, I have not heard consensus going towards that, but I could be > wrong. > > I wrote a Pace that inserted seven words and only changed one element, > feeling that we might be able to come to an agreement on that. This > appears to have been a tactical error... Strawmen are usually tactical errors. > My order of preference: > > PaceFeedIdOrAlternate > PaceFeedIdOrSelf > Current Text > PaceCoConstraintsAreBad "no one has spoken up in favor of the current text" remains true. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 6 23:11:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07183 for ; Wed, 6 Apr 2005 23:11:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3732Baq082715; Wed, 6 Apr 2005 20:02:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3732BGE082714; Wed, 6 Apr 2005 20:02:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3732A4p082700 for ; Wed, 6 Apr 2005 20:02:10 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j37343Xu009180 for ; Wed, 6 Apr 2005 23:04:03 -0400 Message-ID: <4254A2AD.3070405@intertwingly.net> Date: Wed, 06 Apr 2005 23:02:05 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Obs on format-07 References: <75A2ED4B-A70D-11D9-A96A-003065EA6144@geckotribe.com> In-Reply-To: <75A2ED4B-A70D-11D9-A96A-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit An additional observation: neither of the examples in section 1.1 include the summary element. Suggestion: change the "content" in the first (minimal) example to "summary". - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Apr 6 23:20:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07909 for ; Wed, 6 Apr 2005 23:20:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3739RuL083076; Wed, 6 Apr 2005 20:09:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3739RnB083075; Wed, 6 Apr 2005 20:09:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3739QVO083069 for ; Wed, 6 Apr 2005 20:09:26 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12ld2tn.cable.mindspring.com ([69.86.139.183] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJNOX-0003hO-5w; Thu, 07 Apr 2005 03:09:25 +0000 Message-ID: <4254A461.4070607@franklinmint.fm> Date: Wed, 06 Apr 2005 23:09:21 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax@imc.org Subject: Re: Obs on format-07 References: <75A2ED4B-A70D-11D9-A96A-003065EA6144@geckotribe.com> <4254A2AD.3070405@intertwingly.net> In-Reply-To: <4254A2AD.3070405@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > An additional observation: neither of the examples in section 1.1 > include the summary element. Suggestion: change the "content" in the > first (minimal) example to "summary". ""? Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 6 23:39:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09119 for ; Wed, 6 Apr 2005 23:39:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j373UEK5084696; Wed, 6 Apr 2005 20:30:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j373UEAx084695; Wed, 6 Apr 2005 20:30:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j373U8Tb084685 for ; Wed, 6 Apr 2005 20:30:08 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j373U8Xi019178 for ; Wed, 6 Apr 2005 21:30:08 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEK00GTW4E7HR@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 06 Apr 2005 21:30:08 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEK00AB54E6OI@mail.sun.net> for atom-syntax@imc.org; Wed, 06 Apr 2005 21:30:07 -0600 (MDT) Date: Wed, 06 Apr 2005 20:30:37 -0700 From: Tim Bray Subject: Re: PaceCoConstraintsAreBad In-reply-to: <4254A32F.1020601@franklinmint.fm> To: Robert Sayre Cc: Atom Syntax , Sam Ruby Message-id: <4a7f34fda2b9af5be8b06ff7b3c8e523@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 6, 2005, at 8:04 PM, Robert Sayre wrote: >> This pace dropped the requirement for an alternate link. This pace >> dropped the requirement for a summary when content is not present. > > Yes, because the WG has *never* voiced an opinion in favor of that > constraint, You are incorrect. There was an extended discussion, with Mark Pilgrim steadfastly refusing to let the hideous old multipart/alternate go until we had another proposal that had a good accessibility story. There was a Pace, I forget the name, that discarded multipart/alternative and suggested multiple changes, including the requirement that there be summary if there's no content, and it clearly got better-than-rough consensus. > and we fail to meet the requirements of our charter for any definition > of "syndication"that takes prior art into account. Huh? The prior art was considered and the group decided to stiffen the historical rules; largely, as I said, in the interests of accessibility. -Tim From owner-atom-syntax@mail.imc.org Wed Apr 6 23:40:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09174 for ; Wed, 6 Apr 2005 23:40:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j373UVP8084724; Wed, 6 Apr 2005 20:30:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j373UVIT084723; Wed, 6 Apr 2005 20:30:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j373UUGP084717 for ; Wed, 6 Apr 2005 20:30:30 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j373UUK2005523 for ; Wed, 6 Apr 2005 21:30:30 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEK0008X4ET6C@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 06 Apr 2005 21:30:30 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEK00AB54E6OI@mail.sun.net> for atom-syntax@imc.org; Wed, 06 Apr 2005 21:30:29 -0600 (MDT) Date: Wed, 06 Apr 2005 20:31:00 -0700 From: Tim Bray Subject: Re: Obs on format-07 In-reply-to: <4254A461.4070607@franklinmint.fm> To: Robert Sayre Cc: Sam Ruby , atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <75A2ED4B-A70D-11D9-A96A-003065EA6144@geckotribe.com> <4254A2AD.3070405@intertwingly.net> <4254A461.4070607@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 6, 2005, at 8:09 PM, Robert Sayre wrote: > > Sam Ruby wrote: >> An additional observation: neither of the examples in section 1.1 >> include the summary element. Suggestion: change the "content" in the >> first (minimal) example to "summary". > > ""? No. --Tim From owner-atom-syntax@mail.imc.org Wed Apr 6 23:42:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09283 for ; Wed, 6 Apr 2005 23:42:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j373XhX0084916; Wed, 6 Apr 2005 20:33:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j373XhJv084915; Wed, 6 Apr 2005 20:33:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j373Xg2g084909 for ; Wed, 6 Apr 2005 20:33:42 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12ld2tn.cable.mindspring.com ([69.86.139.183] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJNm0-0003sX-2B; Thu, 07 Apr 2005 03:33:40 +0000 Message-ID: <4254AA10.3030603@franklinmint.fm> Date: Wed, 06 Apr 2005 23:33:36 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?windows-1252?Q?Bill_de_h=D3ra?= CC: Atom Syntax Subject: Re: Obs on format-07 References: <425491E7.3020605@dehora.net> In-Reply-To: <425491E7.3020605@dehora.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > > > Hi editors, > > Comments and observations on the 07 draft. > > > ** RNC Schema > > - is valid rnc > > - the schema and the fragments appear to be consistent. > > - both examples validate according to the supplied schema > > - the xhtml fragments in 4.1.3.4 validate when embedded as specified. > > - in 6.4; simple and extension schema forbid the use of the atom > namespace as the top level element in the extension. This is a very > common RNG idiom and I imagine the text should reflect the constraint > assuming that's the consensus of the WG. Note that it cannot generally > be represented in WXS; for example, Trang will convert it to a looser > xsd:any constraint. > > - in 6.4; extension schema allow the use of the atom namespace as child > elements of the extension. I do not recall this being discussed, but > personally am +1 to it. > > - I believe atomfeed and ...? > replace: > [[[ > App B Collected RELAX NG Compact Schema > ]]] > > with: > "App B RELAX NG Compact Schema" > > reason: not all the schema is presented in fragment form, so the title > is incorrect. Correct. In 1.2, how about "A complete schema appears in Appendix B." > ** 1. Introduction > > p2. the last sentence requires a for-example or should be struck. > > reason: qualify what 'other purposes' might be. > > > ** 1.1 Examples: > > Please use a namespace prefix for both or at least one of the examples. > > reason: 1) default namespaces are not robust (I offer requirement of > xhtml:div as evidence), examples in XML formats should not propagate the > practice. 2) example markup is not consistent with naming convention > used to call out specified elements. > > Please add a element property to an entry that is not from the format > (ie Dublin Core) > > reason: demonstrate what extensible indicates upfront. I am concerned that any extension element in the examples will create a procedural issue. I am also concerned that the target audience for a prefixed example would be rather small. > > ** 2. Atom Documents > > p5: this paragraph can be struck without loss of meaning. > > reason: adds no specification value. Agree. > > p8: replace: > [[[ > Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986]. For > resolution, IRIs can easily be converted to URIs. When comparing IRIs > serving as atom:id values, they MUST NOT be converted to URIs. By > definition, every URI is an IRI, so any URI can be used where an IRI is > needed. > ]]] > > with the following: > > "Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986]. By > definition, every URI is an IRI, so any URI can be used where an IRI is > needed. Note: > > 1. For purposes of resolution, IRIs MAY be converted to URIs. > > 2. For purposes of comparison, where IRIs act as atom:id values, they > MUST NOT be converted to URIs." > > Also, if 'resolution' is a term taken from some spec it should be called > out as such. 'resolution' is a little sloppy. How about this: [[[ Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986]. IRIs can easily be converted to URIs, and every URI is an IRI, so any URI can be used where an IRI is needed.. When comparing IRIs serving as atom:id values, they MUST NOT be converted to URIs. By definition, ]]] > > reason: p8 does not read clearly enough to provide implementor guidance. > > ob: I think this indicates an implementor burden of using IRIs. I need > to write conversion code differently depending on whether I'm resolving > or comparing. Yes, but this is as specified by RFC3987, section 5.1, p4. > > p10: remove the following clause: > [[[but may be defined by an extension to Atom.]]] > > reason: the caveat adds no specification value and provides questions > without answers (does 'may' mean 'might' above? defined by who? etc). Agree. > > > ** 3.1.1 The "type" Attribute > > replace: > [[[ > Note that MIME media types [RFC2045] are not acceptable values for the > "type" attribute. > ]]] > > with: > > "MIME media types [RFC2045] MUST NOT be used as values for the "type" > attribute." > > reason: state the specification as specification not as a side note. Agree. > > > ** 3.1.1.3 XHTML > > replace > [[[ > The following example assumes that the XHTML namespace has been bound to > the "xh" prefix earlier in the document: > ]]] > > with > > "Note: the following example is not well formed unless the XHTML > namespace has been bound previously to the "xh" prefix in the document:" > > reason: clearly indicate what conformance prefix binding entails. > Tim covered this. > > > ** 4.1.1 The "atom:feed" Element > > replace: > [[[ > * atom:feed elements MUST contain exactly one atom:author element, > UNLESS all of the atom:feed element's child atom:entry elements contain > an atom:author element. atom:feed elements MUST NOT contain more than > one atom:author element. > ]]] > > with: > "* atom:feed elements MUST contain an atom:author element, UNLESS all of > the atom:feed element's child atom:entry elements contain an atom:author > element. > > * atom:feed elements MUST NOT contain more than one atom:author element." > > reason: give each spec its own bullet point. Agree. > > replace: > [[[ > * atom:feed elements MUST NOT contain more than one atom:link element > with a rel attribute value of "alternate" that has the same type > attribute value. If a feed's atom:link element with type="alternate" > resolves to an HTML document, then that document SHOULD have a > autodiscovery link element [Atom-autodiscovery] that reflects back to > the feed. atom:feed elements MAY contain additional atom:link elements > beyond those described above. > ]]] > > with: > "* atom:feed elements MUST NOT contain more than one atom:link element > with a rel attribute value of "alternate" which have the same type > attribute value. > > * If a feed's atom:link element with type="alternate" resolves to an > HTML document, then that document SHOULD have a autodiscovery link > element [Atom-autodiscovery] that reflects back to the feed. > > * atom:feed elements MAY contain additional atom:link elements with > values of the rel attribute other than 'alternate' and 'self'." > > reason: give each spec its own bullet point. Change "that has" to "which > have" as we're dealing with plurals. Agree. > > > ** 4.1.2 The "atom:entry" Element > > replace: > [[[ > * atom:entry elements MUST contain exactly one atom:author element, > unless the atom:entry contains an atom:source element which contains an > atom:author element, or, in an Atom Feed Document, the atom:feed element > contains an atom:author element itself. atom:entry elements MUST NOT > contain more than one atom:author element. > ]]] > > with: > "* atom:entry elements MUST contain exactly one atom:author element, > unless the atom:entry contains an atom:source element which contains an > atom:author element, or, in an Atom Feed Document, the atom:feed element > contains an atom:author element itself. > > * atom:entry elements MUST NOT contain more than one atom:author element." > > reason: give each spec its own bullet point. Agree. > > > replace: > [[[ > * atom:entry elements that contain no child atom:content element MUST > contain at least one atom:link element with a rel attribute value of > "alternate". atom:entry elements MUST NOT contain more than one > atom:link element with a rel attribute value of "alternate" that has the > same combination of type and hreflang attribute values. atom:entry > elements MAY contain additional atom:link elements beyond those > described above. > ]]] > > with: > "* atom:entry elements that contain no child atom:content element MUST > contain at least one atom:link element with a rel attribute value of > "alternate". > > * atom:entry elements MUST NOT contain more than one atom:link element > with a rel attribute value of "alternate" which have the same > combination of type and hreflang attribute values. > > * atom:entry elements MAY contain additional atom:link elements with > values of the rel attribute other than 'alternate'." > > reason: give each spec its own bullet point. Change "that has" to "which > have" as we're dealing with plurals. > > Agree > > ** 4.2.7 The "atom:id" Element > > replace: > [[[ > Because of the risk of confusion between IRIs that would be equivalent > if dereferenced, the following normalization strategy is strongly > encouraged when generating atom:id elements: > ]]] > > with: > "Because of the risk of confusion between IRIs that would be equivalent > if dereferenced, the following normalization strategy SHOULD be applied > when generating atom:id elements:" > reason: > > reason: prefer operational text; strongly encouraged sounds very like a > SHOULD. Agree. > > > ** 6.4.1 Simple Extension Elements > > add: > > > > add to end of para > > "simpleExtensionElement = > element * - atom:* { > text > }" > > > ** 6.4.2 Structured Extension Elements > > "structuredExtensionElement = > element * - atom:* { > (attribute * { text }+, > (text|anyElement)*) > | (attribute * { text }*, > (text?, anyElement+, (text|anyElement)*)) > }" > Agree. > > ** General ** > > ** references > > [Atom-autodiscovery] Pilgrim, M., “Atom Feed Autodiscovery”, > work-in-progress, August 2004. > > I'm not sure Atom need be depending on this document. I probably missed > that thread where we said it was ok. We shouldn't be at all. We should ditch this reference and the sentence that refers to it. > > add to the informative references: > > [RELAX-NC] OASIS Technical Committee: Committee Specification 21, > “RELAX NG Compact Syntax”, November 2002. > > fyi:http://www.oasis-open.org/committees/relax-ng/compact-20021121.html > > > ** ABNF > > Drop. > > in 1.2, remove: > [[[ > Some sections of this specification are illustrated with Augmented > Backus-Naur Form (ABNF), a format used to represent permissible strings > in a protocol or language, as defined in [RFC2234]. > ]]] > > in 9.1 remove: > > [[[ > [RFC2234] Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax > Specifications: ABNF”, RFC 2234, November 1997. > ]] > > reason: ABNF is used in one place: ABNF is required to understand the spec, because we refer to rules from other specs. > > 4.2.9.2 The "rel" Attribute, p1 > > and referred to in 3.3. It's incidental enough to be dropped. > > > ** Figures > > Please add figure captions for all samples, bnf and rnc fragments. If > you require someone to do this, I will do it. OK > > ** Replace specification keywords in lowercase (argghh!) OK. From owner-atom-syntax@mail.imc.org Wed Apr 6 23:52:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09671 for ; Wed, 6 Apr 2005 23:52:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j373hNJM085521; Wed, 6 Apr 2005 20:43:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j373hNHR085520; Wed, 6 Apr 2005 20:43:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j373hN26085514 for ; Wed, 6 Apr 2005 20:43:23 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 0B75FA3214; Wed, 6 Apr 2005 23:43:21 -0400 (EDT) In-Reply-To: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6bbfe573245b3d48670121d267cd7898@mnot.net> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: AD Review Comments and Questions: draft-ietf-atompub-format-07 Date: Wed, 6 Apr 2005 20:43:20 -0700 To: "Scott Hollenbeck" X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Done; http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/ 000676.html Just curious; when/how does the ietf-types list switch over to @iana.org (as per draft-freed-media-type-reg)? On Apr 5, 2005, at 8:39 AM, Scott Hollenbeck wrote: > The MIME media type registration template included in section 7 MUST be > submitted to the ietf-types list (ietf-types@alvestrand.no) for > review. A > two-week review period is standard for requests to register new types > in the > standards tree. Please see the list archives [1] for samples if help > is > needed in crafting a review request and please send the request ASAP. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Apr 6 23:54:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09882 for ; Wed, 6 Apr 2005 23:54:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j373k89E085772; Wed, 6 Apr 2005 20:46:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j373k8ui085771; Wed, 6 Apr 2005 20:46:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j373k7DZ085764 for ; Wed, 6 Apr 2005 20:46:07 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12ld2tn.cable.mindspring.com ([69.86.139.183] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJNy0-00040f-1Q; Thu, 07 Apr 2005 03:46:04 +0000 Message-ID: <4254ACF6.6060605@franklinmint.fm> Date: Wed, 06 Apr 2005 23:45:58 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax , Sam Ruby Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <4a7f34fda2b9af5be8b06ff7b3c8e523@sun.com> In-Reply-To: <4a7f34fda2b9af5be8b06ff7b3c8e523@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Apr 6, 2005, at 8:04 PM, Robert Sayre wrote: > >>> This pace dropped the requirement for an alternate link. This pace >>> dropped the requirement for a summary when content is not present. >> >> >> Yes, because the WG has *never* voiced an opinion in favor of that >> constraint, > > > You are incorrect. There was an extended discussion, with Mark Pilgrim > steadfastly refusing to let the hideous old multipart/alternate go until > we had another proposal that had a good accessibility story. I'm very familiar with that discussion, because I am the one who took the time to work through it, by parrying something like 20 insults. http://www.imc.org/atom-syntax/mail-archive/msg09362.html > There was > a Pace, I forget the name, that discarded multipart/alternative and > suggested multiple changes, including the requirement that there be > summary if there's no content, and it clearly got better-than-rough > consensus. That would be http://www.intertwingly.net/wiki/pie/PaceReformedContent3. The list traffic around that shows a clear lack of consensus on this very topic, with many folks making the never-explained assertion that an entry without content or summary is somehow less-accessible to some group of people. > >> and we fail to meet the requirements of our charter for any definition >> of "syndication"that takes prior art into account. > > > Huh? The prior art was considered and the group decided to stiffen the > historical rules; largely, as I said, in the interests of accessibility. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 7 00:33:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18038 for ; Thu, 7 Apr 2005 00:33:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j374NvX0088795; Wed, 6 Apr 2005 21:23:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j374NvjW088794; Wed, 6 Apr 2005 21:23:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j374Num8088784 for ; Wed, 6 Apr 2005 21:23:56 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc11) with SMTP id <2005040704234801100fokq0e>; Thu, 7 Apr 2005 04:23:48 +0000 Date: Wed, 6 Apr 2005 22:23:48 -0600 Subject: Re: PaceCoConstraintsAreBad Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <42549D8D.5090708@intertwingly.net> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, April 6, 2005, at 08:40 PM, Sam Ruby wrote: > My order of preference: > > PaceFeedIdOrAlternate > PaceFeedIdOrSelf > Current Text > PaceCoConstraintsAreBad > To summarize what elements would be required under each, all four require atom:title and atom:updated. Additionally: Current Text: Requires atom:link[@rel="alternate"]. PaceFeedIdOrAlternate: Requires either atom:link[@rel="alternate"] or atom:id. PaceFeedIdOrSelf: Requires either atom:link[@rel="self"] or atom:id. PaceCoConstraintsAreBad: SHOULD have atom:link[@rel="alternate"]; Requires atom:id and atom:author? (the abstract says so, but the proposed text doesn't). My preferences (which, below the first one, shifted as I typed my comments below--score one for "principled reasoning"): PaceFeedIdOrSelf PaceCoConstraintsAreBad PaceFeedIdOrAlternate Current Text Comments: * PaceFeedIdOrSelf: atom:id and atom:link[@rel="self"] are somewhat interchangable as feed identifiers. * PaceCoConstraintsAreBad: less change at this point in time would be more comfortable, and I'm undecided about atom:author...which is okay, because the Pace is too ;^). But it's probably an improvement over the current situation. * PaceFeedIdOrAlternate: atom:id and atom:link[@rel="alternate"] don't seem to me to fill similar enough roles to be alternative requirements, but at least atom:link[@rel="alternate"] wouldn't be absolutely required * Current Text: Requiring atom:link[@rel="alternate"] just seems unnecessary, and is unreasonable in some cases From owner-atom-syntax@mail.imc.org Thu Apr 7 02:24:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16269 for ; Thu, 7 Apr 2005 02:24:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j376G4DR025820; Wed, 6 Apr 2005 23:16:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j376G4Jk025819; Wed, 6 Apr 2005 23:16:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j376G2sF025791 for ; Wed, 6 Apr 2005 23:16:03 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 7 Apr 2005 12:15:54 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 07 Apr 2005 16:15:54 +1000 Subject: Re: Obs on format-07 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <75A2ED4B-A70D-11D9-A96A-003065EA6144@geckotribe.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> "Note: the following example is not well formed unless the XHTML >> namespace has been bound previously to the "xh" prefix in the >> document:" tangent: perhaps we could also insert a note along the lines of ... "Note: @type="XHTML" does not automatically imbue the contents of the atom:content element with the appropriate or necessary XML namespace." ... point being to alert XML ignorant to a possible problem. Certainly can be better worded. e. From owner-atom-syntax@mail.imc.org Thu Apr 7 04:35:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27565 for ; Thu, 7 Apr 2005 04:35:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j378JcQH071605; Thu, 7 Apr 2005 01:19:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j378Jc1Z071604; Thu, 7 Apr 2005 01:19:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by above.proper.com (8.12.11/8.12.9) with SMTP id j378JbOA071565 for ; Thu, 7 Apr 2005 01:19:37 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 48089 messnum 6385360 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 7 Apr 2005 08:19:31 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail00.svc.cra.dublin.eircom.net (qp 48089) with SMTP; 7 Apr 2005 08:19:31 -0000 Message-ID: <4254ED10.9080702@dehora.net> Date: Thu, 07 Apr 2005 09:19:28 +0100 From: =?windows-1252?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: Obs on format-07 References: <425491E7.3020605@dehora.net> <4254AA10.3030603@franklinmint.fm> In-Reply-To: <4254AA10.3030603@franklinmint.fm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > > Bill de hÓra wrote: >> >> - I believe atomfeed and > > > ...? I was going to say something about schematron - don't mind it. The spec will be clearer for leaving the schematron in. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 7 07:55:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12822 for ; Thu, 7 Apr 2005 07:55:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37BkdKu044946; Thu, 7 Apr 2005 04:46:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37BkdGT044945; Thu, 7 Apr 2005 04:46:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37BkcKM044934 for ; Thu, 7 Apr 2005 04:46:38 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 07 Apr 2005 07:46:37 -0400 id 005900C8.42551D9D.0000424C Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Mark Nottingham'" Cc: atom-syntax@imc.org Subject: RE: AD Review Comments and Questions: draft-ietf-atompub-format-07 Date: Thu, 7 Apr 2005 07:46:17 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749C9B1@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <6bbfe573245b3d48670121d267cd7898@mnot.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit One is an alias for the other. They're currently interchangeable from a sending perspective. -Scott- > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Wednesday, April 06, 2005 11:43 PM > To: Scott Hollenbeck > Cc: atom-syntax@imc.org > Subject: Re: AD Review Comments and Questions: > draft-ietf-atompub-format-07 > > > Done; > http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/ > 000676.html > > Just curious; when/how does the ietf-types list switch over to > @iana.org (as per draft-freed-media-type-reg)? > > > On Apr 5, 2005, at 8:39 AM, Scott Hollenbeck wrote: > > > The MIME media type registration template included in > section 7 MUST be > > submitted to the ietf-types list (ietf-types@alvestrand.no) for > > review. A > > two-week review period is standard for requests to register > new types > > in the > > standards tree. Please see the list archives [1] for > samples if help > > is > > needed in crafting a review request and please send the > request ASAP. > > -- > Mark Nottingham http://www.mnot.net/ > > From owner-atom-syntax@mail.imc.org Thu Apr 7 09:21:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21030 for ; Thu, 7 Apr 2005 09:21:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37DALnr070254; Thu, 7 Apr 2005 06:10:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37DALHP070253; Thu, 7 Apr 2005 06:10:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37DAJxA070244 for ; Thu, 7 Apr 2005 06:10:20 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12ld2tn.cable.mindspring.com ([69.86.139.183] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJWlz-0001Hq-Ow; Thu, 07 Apr 2005 13:10:15 +0000 Message-ID: <42553136.6040906@franklinmint.fm> Date: Thu, 07 Apr 2005 09:10:14 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Atom Syntax Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> In-Reply-To: <425528F7.2090603@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > If, instead, it opens the door for multiple changes without explicit > rationale; at the last minute; overturning carefully formed consensus; > then it was not. Uh, so your changes are ok, but mine aren't? We continue the lovely pattern of DOSing proposals. > > I am willing to go with PaceFeedIdOrSelf. I'm not. link @rel="self" is just horrible, and invention anyway. I guess the people who want to ditch the alternate will be making their case in Last Call. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 7 09:41:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22969 for ; Thu, 7 Apr 2005 09:41:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37DXnZB072287; Thu, 7 Apr 2005 06:33:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37DXnqP072286; Thu, 7 Apr 2005 06:33:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37DXmj0072278 for ; Thu, 7 Apr 2005 06:33:48 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j37DZCjN009359; Thu, 7 Apr 2005 09:35:14 -0400 Message-ID: <42553698.40101@intertwingly.net> Date: Thu, 07 Apr 2005 09:33:12 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> In-Reply-To: <42553136.6040906@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > Sam Ruby wrote: > >> If, instead, it opens the door for multiple changes without explicit >> rationale; at the last minute; overturning carefully formed consensus; >> then it was not. > > Uh, so your changes are ok, but mine aren't? We continue the lovely > pattern of DOSing proposals. Unfair. I've withdrawn my proposal. At this point, small surgical changes to address specific concerns may (or may not) be acceptable. Wholesale changes with little rationale are less likely to be so. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Apr 7 09:54:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24217 for ; Thu, 7 Apr 2005 09:54:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37DhfAQ073146; Thu, 7 Apr 2005 06:43:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37DhfRl073145; Thu, 7 Apr 2005 06:43:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37DheAF073134 for ; Thu, 7 Apr 2005 06:43:40 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j37CmgIY004905; Thu, 7 Apr 2005 08:48:43 -0400 Message-ID: <42552BB3.9010006@intertwingly.net> Date: Thu, 07 Apr 2005 08:46:43 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Robert Sayre , atom-syntax@imc.org Subject: Re: Obs on format-07 References: <75A2ED4B-A70D-11D9-A96A-003065EA6144@geckotribe.com> <4254A2AD.3070405@intertwingly.net> <4254A461.4070607@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Apr 6, 2005, at 8:09 PM, Robert Sayre wrote: > >> Sam Ruby wrote: >> >>> An additional observation: neither of the examples in section 1.1 >>> include the summary element. Suggestion: change the "content" in the >>> first (minimal) example to "summary". >> >> ""? > > No. --Tim Perhaps it would help if I was more clear. If you start with this: Some text. And you change content to summary, you end up with this: Some text. I happen to be of the opinion that in terms of linear spec space, these two examples with be the most cost effective portions of the spec. Most people, after seeing these, will have few questions and will only need to take seek out other sections if they have specific questions. Coupled with the existance of the feedvalidator, this isn't such a bad thing. I'd like such people to have been exposed to both summary and content elements. Used in a manner that most people would find helpful: i.e., non-empty. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Apr 7 09:57:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24647 for ; Thu, 7 Apr 2005 09:57:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37DoIZO073728; Thu, 7 Apr 2005 06:50:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37DoIgH073727; Thu, 7 Apr 2005 06:50:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37DoHv0073721 for ; Thu, 7 Apr 2005 06:50:17 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJXOA-0001mb-AI; Thu, 07 Apr 2005 13:49:42 +0000 Message-ID: <42553A72.2090207@franklinmint.fm> Date: Thu, 07 Apr 2005 09:49:38 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Atom Syntax Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> In-Reply-To: <42553698.40101@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > At this point, small surgical changes to address specific concerns may > (or may not) be acceptable. Wholesale changes with little rationale are > less likely to be so. Well, who really cares anyway. I'll get the draft ready. Nobody propose any 'wholesale changes' in the meantime, OK? Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 7 09:59:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24834 for ; Thu, 7 Apr 2005 09:59:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Dhgb6073150; Thu, 7 Apr 2005 06:43:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37DhggW073147; Thu, 7 Apr 2005 06:43:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37DheAH073134 for ; Thu, 7 Apr 2005 06:43:41 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j37Cb2FG003472; Thu, 7 Apr 2005 08:37:06 -0400 Message-ID: <425528F7.2090603@intertwingly.net> Date: Thu, 07 Apr 2005 08:35:03 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> In-Reply-To: <4254A32F.1020601@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > Sam Ruby wrote: > >> Content remains optional. > > The pace did not drop the requirement for a link element in the absence > of content. OK, I missed that. What else did I miss at this late date? As it stands, this Pace declares co-constraints bad, selectively removes a few co-constraints, and leaves others, with little rhyme or reason. >> Am I misreading the Pace? The abstract seems clear enough... >> >> While I agree with your recent statement that "no one has spoken up in >> favor of the current text", I resonate more with Paul's recent >> statement[1] that: >> >> It doesn't matter whether or not they are "too controversial"; the >> spec is frozen for significant technical changes. >> >> Unless, of course, the WG decides we really do want to open it all up >> again an take another probably four months of deciding what else we >> want to add and change. We can do that by amending our charter. So >> far, I have not heard consensus going towards that, but I could be >> wrong. >> >> I wrote a Pace that inserted seven words and only changed one element, >> feeling that we might be able to come to an agreement on that. This >> appears to have been a tactical error... > > Strawmen are usually tactical errors. It was a serious proposal. And if it results in a clear consensus around PaceFeedIdOrSelf, then it was useful. If, instead, it opens the door for multiple changes without explicit rationale; at the last minute; overturning carefully formed consensus; then it was not. >> My order of preference: >> >> PaceFeedIdOrAlternate >> PaceFeedIdOrSelf >> Current Text >> PaceCoConstraintsAreBad > > > "no one has spoken up in favor of the current text" remains true. I am willing to go with PaceFeedIdOrSelf. A number of people have expressed support for it. I don't know if it meets a threshold or not - at the moment the bar is pretty high. And the number of active proposals is troublesome. I've marked PaceIdOrAlternate withdrawn. I remain -1 on PaceCoConstraintsAreBad. > Robert Sayre - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Apr 7 10:01:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25156 for ; Thu, 7 Apr 2005 10:01:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37DtB2s074123; Thu, 7 Apr 2005 06:55:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37DtBjP074122; Thu, 7 Apr 2005 06:55:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37DtAFv074115 for ; Thu, 7 Apr 2005 06:55:10 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 13833 invoked by uid 17064); 7 Apr 2005 13:55:10 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.105.166]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 7 Apr 2005 13:55:10 -0000 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <5fc9a245d2322ebee4699ee1cf10187a@bblfish.net> References: <2096236859555a4138b511183da47a30@bblfish.net> <424D8A53.3010308@cegetel.net> <5f7866c4cafffaed9d948c8e411ae7bf@bblfish.net> <424F1779.6010007@cegetel.net> <425059F2.6040709@cegetel.net> <5fc9a245d2322ebee4699ee1cf10187a@bblfish.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <68c351995d0c149a902b0682f7f1c613@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceAlternateLinkWeakening Date: Thu, 7 Apr 2005 15:55:06 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Here is a nice small surgical change. I am not sure if I have convinced Thomas Broyer with the diagrams I put online, but I am still very happy with the following replacement, after having carefully looked at the criticisms. Proposal A ---------- replace [[ The value "alternate" signifies that the IRI in the value of the href attribute identifies an alternate version of the resource described by the containing element. ]] with: [[ The value "alternate" signifies that the containing element is an alternative representation of the resource identified by the IRI in the value of the href attribute. ]] From owner-atom-syntax@mail.imc.org Thu Apr 7 10:06:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21029 for ; Thu, 7 Apr 2005 09:21:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37DEMN1070626; Thu, 7 Apr 2005 06:14:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37DEMvR070625; Thu, 7 Apr 2005 06:14:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37DEL1L070619 for ; Thu, 7 Apr 2005 06:14:21 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12ld2tn.cable.mindspring.com ([69.86.139.183] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJWpB-0001JB-N1; Thu, 07 Apr 2005 13:13:33 +0000 Message-ID: <425531FC.4040703@franklinmint.fm> Date: Thu, 07 Apr 2005 09:13:32 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Tim Bray , atom-syntax@imc.org Subject: Re: Obs on format-07 References: <75A2ED4B-A70D-11D9-A96A-003065EA6144@geckotribe.com> <4254A2AD.3070405@intertwingly.net> <4254A461.4070607@franklinmint.fm> <42552BB3.9010006@intertwingly.net> In-Reply-To: <42552BB3.9010006@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Tim Bray wrote: >> On Apr 6, 2005, at 8:09 PM, Robert Sayre wrote: >>> >>> ""? >> >> >> No. --Tim > > > Some text. I've incorporated Sam's suggested wording. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 7 12:58:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14270 for ; Thu, 7 Apr 2005 12:58:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37GoH16088873; Thu, 7 Apr 2005 09:50:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37GoHIi088872; Thu, 7 Apr 2005 09:50:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Gnkca088826 for ; Thu, 7 Apr 2005 09:50:16 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j37GnkK2013372 for ; Thu, 7 Apr 2005 10:49:46 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEL00EOG5EYOK@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 07 Apr 2005 10:49:46 -0600 (MDT) Received: from [192.168.102.100] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEL00ASL5EXO6@mail.sun.net> for atom-syntax@imc.org; Thu, 07 Apr 2005 10:49:46 -0600 (MDT) Date: Thu, 07 Apr 2005 09:50:16 -0700 From: Tim Bray Subject: Re: PaceCoConstraintsAreBad In-reply-to: <4254ACF6.6060605@franklinmint.fm> To: Robert Sayre Cc: Atom Syntax , Sam Ruby Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <4a7f34fda2b9af5be8b06ff7b3c8e523@sun.com> <4254ACF6.6060605@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 6, 2005, at 8:45 PM, Robert Sayre wrote: >>> Yes, because the WG has *never* voiced an opinion in favor of that >>> constraint, >> You are incorrect. There was an extended discussion, with Mark >> Pilgrim steadfastly refusing to let the hideous old >> multipart/alternate go until we had another proposal that had a good >> accessibility story. > > I'm very familiar with that discussion, because I am the one who took > the time to work through it, by parrying something like 20 insults. I'm sorry; Paul and I waded through the WG email in detail and issued a detailed consensus call and got no significant push-back and the results went into the draft. > The list traffic around that shows a clear lack of consensus on this > very topic, with many folks making the never-explained assertion that > an entry without content or summary is somehow less-accessible to some > group of people. Actually, the argument was that if the content is either non-textual or remote, a summary is beneficial to accessibility. I agree that many people made this argument, sufficient in the co-chairs' minds to establish rough consensus. A flurry of Paces has been filed. That's good. In my opinion, none of them are very material to the kind of content we're seeking from the broader IETF community, and it is appropriate at this time to seek that commentary with the draft we have now (modulo our AD's issues), which I have no problem in asserting enjoys rough-consensus support. Once that has launched, we'll figure out an orderly way to set up a discussion on the Paces from the last week. -Tim From owner-atom-syntax@mail.imc.org Thu Apr 7 13:13:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15829 for ; Thu, 7 Apr 2005 13:13:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37H3xSi090113; Thu, 7 Apr 2005 10:03:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37H3xI3090112; Thu, 7 Apr 2005 10:03:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37H3vO1090105 for ; Thu, 7 Apr 2005 10:03:58 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJaQ5-00048U-9w; Thu, 07 Apr 2005 17:03:53 +0000 Message-ID: <425567F6.1070608@franklinmint.fm> Date: Thu, 07 Apr 2005 13:03:50 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax , Sam Ruby Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <4a7f34fda2b9af5be8b06ff7b3c8e523@sun.com> <4254ACF6.6060605@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > Actually, the argument was that if the content is either non-textual or > remote, a summary is beneficial to accessibility. I agree that many > people made this argument, sufficient in the co-chairs' minds to > establish rough consensus. I understand the argument if the content is non-textual, sort of. For example, the thoroughly-vetted SVG format has no required metadata fields. Perhaps it would be a good idea to have an accessibility expert review the document and identify requirements that ensure accessibility. I asked back at the time. No one answered, but they did mention "screwing blind people" or something like that. Until it is reviewed, I consider those requirements a bug. > A flurry of Paces has been filed. That's good. In my opinion, none of > them are very material to the kind of content we're seeking from the > broader IETF community... Fully agree. > Once that > has launched, we'll figure out an orderly way to set up a discussion on > the Paces from the last week. OK. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 7 13:41:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18136 for ; Thu, 7 Apr 2005 13:41:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37HZ3SI093601; Thu, 7 Apr 2005 10:35:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37HZ3If093600; Thu, 7 Apr 2005 10:35:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37HZ2Fj093594 for ; Thu, 7 Apr 2005 10:35:02 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j37HYgmm009681 for ; Thu, 7 Apr 2005 13:34:48 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CXQ40556 (AUTH bob@wyman.us); Thu, 7 Apr 2005 13:34:40 -0400 (EDT) Message-Id: <200504071734.CXQ40556@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: Subject: One reason we have duplicates entries is that we have duplicate feeds... Date: Thu, 7 Apr 2005 13:34:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcU7l/y7sBfsR03XTf6I9N6Cx4cDlg== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit As many are aware, the Tim Bray[1] and others have recently been railing on the subject of duplicate entries being delivered by aggregation services and/or search engines like PubSub, Technorati, Feedster, etc. As unexpected as this may sound, I am quite confident that when Atom V1.0 is released and starts to be used, the problem of duplicates will get worse -- unless something (probably quite simple) is done. A major part of the problem with duplicate entries is that people publish duplicate feeds. The introduction of Atom V1.0 will result in even more duplicate feeds being produced... This is not because of "bugs" in the producers of synthetic feeds. A major cause of duplicates in at least some of the existing services is the fact that bloggers insist on engaging in the apparently illogical and wasteful practice of publish multiple versions of their feeds and thus duplicates of their entries or items. Often blogs will offer at least one flavor of RSS as well as Atom. Those that don't offer Atom will often offer at least two flavors of RSS. Some sites provide as many as six or seven distinct versions of their feeds in addition to a sometimes large number of "category" feeds (each of which is offered in multiple encodings) that contain nothing but duplicates of entries/items found in some primary feed. Unfortunately, while RSS and Atom both contain mechanisms to identify their "HTML" alternates, there isn't any clear mechanism available to discover alternate feeds. In theory, if such means existed, automated processors of large numbers of feeds could selectively ignore duplicate feeds... The process of recognizing duplicates within a single feed is relatively straight forward and is widely implemented not only by news aggregator clients but also by the aggregating services. (I believe the most common method is to generate an MD5 hash for each entry/item and doing the obvious processing.) Problems arise, however, when one attempts to recognize duplicates across feeds which may have different information-carrying capacities (i.e. RSS, RDF and Atom are different). Recognizing duplicate feeds is made particularly difficult if only because of the practice that many sites have of producing "category" feeds that are organized to present different selections of the posts for a single blog. The fact that an entry has been published in one or another "category feed" is, in itself, information that may be useful to some readers. In any case, there is no way without using human, meat-machine based inspection to determine which of many feeds is the "primary" feed... It should also be noted that if an aggregation service (such as PubSub) allows users to subscribe to content based on the "source feed" of the entry, the aggregation service is forced to read all the feeds that it can find -- since any findable feed is something that some user might want subscribe to... This issue becomes particularly troubling in contexts like FeedMesh where aggregators are expected to share their knowledge of feed updates with each other. Issues might arise if some aggregators are selectively ignoring feeds or processing the feeds but not publishing their results to the FeedMesh. Even if the aggregator could establish that two feeds carried identical content, it would be difficult to stop processing one of the feeds since someone might wish to subscribe to it... Admittedly, one can imagine that an aggregator might install a rule that says: "Any subscription to feed A should be read as a subscription to feed B." However, that would require the aggregator to assume that simply because two feeds had substantially identical content in the past, that they would have identical content in the future. This is not an easy assumption to make without some explicit indication of feed equivalence from the producer of the feed. We could go further and require that the aggregator constantly "check" its assumptions and if the two feeds diverge then uninstall the rule. This is getting complex... Too complex. Tim suggests that aggregators should be able to rely simply on atom:id to detect duplicates. However, as has often been pointed out, applying this rule in an intermediary like PubSub would simply make PubSub a marvelously efficient tool for denial of service attacks. I.e. if I didn't like something you published, I would simply publish something in my blog that had the same atom:id as something you had published. PubSub and other synthetic feed producers would then flush your post from the system and replace it with my post... Not good -- and not avoidable given the current loose rules for defining instances of atom:id. This issue of duplicate detection has come up many times in this forum and has never been dealt with seriously as far as I can tell. The current Atom draft continues to fail to address the issue. Simply complaining isn't getting us anywhere even as the introduction of Atom V1.0 makes the problem worse. One thing that we could do in the short term to reduce the number of duplicate feeds is to define metadata that would allow feed publishers to describe the relationships between feeds and describe the content of different feeds. If, when reading a feed, I could be informed that this feed was a duplicate of another "preferred" feed, I could switch to the preferred feed and stop reading the duplicate. I could use this knowledge to map subscriptions to the duplicate feeds to their equivalents. This would be wonderful in the transition from Atom .03 to Atom V1.0... (i.e. if the old format feed could point to the newer version, we'd all eventually stop reading the old format feed.) For instance: If these link rel types are acceptable to people, we should probably define equivelant syntax to be inserted into old Atom feeds to allow the transition to the new atom as well as define extensions to the various flavors of RSS. If we can implement this minor extension, we may see many fewer duplicate feeds being consumed and thus fewer duplicate entries. Comments? bob wyman [1] http://www.tbray.org/ongoing/When/200x/2005/04/03/Atom-Now From owner-atom-syntax@mail.imc.org Thu Apr 7 13:49:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18868 for ; Thu, 7 Apr 2005 13:49:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37HiXwd094781; Thu, 7 Apr 2005 10:44:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37HiXdT094780; Thu, 7 Apr 2005 10:44:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37HiWX5094773 for ; Thu, 7 Apr 2005 10:44:32 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJb3M-0004aW-Ry; Thu, 07 Apr 2005 17:44:28 +0000 Message-ID: <42557179.80600@franklinmint.fm> Date: Thu, 07 Apr 2005 13:44:25 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... References: <200504071734.CXQ40556@ms8.netsolmail.com> In-Reply-To: <200504071734.CXQ40556@ms8.netsolmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Unfortunately, while RSS and Atom > both contain mechanisms to identify their "HTML" alternates, there isn't any > clear mechanism available to discover alternate feeds. Without responding to the rest of the message, I'll note that this statement is somewhat inaccurate wrt Atom. You can point to an alternate feed like this Of course, you can't have two alternates with the same media type... Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 7 13:56:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19501 for ; Thu, 7 Apr 2005 13:56:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37HmKFJ095293; Thu, 7 Apr 2005 10:48:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37HmKYD095292; Thu, 7 Apr 2005 10:48:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from localhost.localdomain (air643.startdedicated.com [69.64.38.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37HmJhP095285 for ; Thu, 7 Apr 2005 10:48:19 -0700 (PDT) (envelope-from david@blojsom.com) Received: (qmail 22876 invoked from network); 7 Apr 2005 17:28:11 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 7 Apr 2005 17:28:11 -0000 Received: from air643.startdedicated.com (air643.startdedicated.com [69.64.38.51]) by webmail.blojsom.com (IMP) with HTTP for ; Thu, 7 Apr 2005 13:28:11 -0400 Message-ID: <1112894891.42556daba6e5e@webmail.blojsom.com> Date: Thu, 7 Apr 2005 13:28:11 -0400 From: David Czarnecki To: atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... References: <200504071734.CXQ40556@ms8.netsolmail.com> In-Reply-To: <200504071734.CXQ40556@ms8.netsolmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 69.64.38.51 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit This seems similar to what exists in Really Simply Discoverability in the individual element [1]. ----- # has 4 required attributes. * "preferred" is a boolean and takes either "true" or "false". The point is to allow weblog software to list all the APIs supported, but choose which one to "recommend" to the client software. Only one API should set as prefered. ----- This couldn't be another/new attribute on the site feed autodiscovery links? As opposed to the link rel types proposed below. -David [1] - http://archipelago.phrasewise.com/rsd#ODoxNjozMSBBTQdbdb Quoting Bob Wyman : > One thing that we could do in the short term to reduce the number of > duplicate feeds is to define metadata that would allow feed publishers to > describe the relationships between feeds and describe the content of > different feeds. If, when reading a feed, I could be informed that this feed > was a duplicate of another "preferred" feed, I could switch to the preferred > feed and stop reading the duplicate. I could use this knowledge to map > subscriptions to the duplicate feeds to their equivalents. This would be > wonderful in the transition from Atom .03 to Atom V1.0... (i.e. if the old > format feed could point to the newer version, we'd all eventually stop > reading the old format feed.) > For instance: > > href="http://example.org/feed.xml"/> > href="http://example.org/fullfeed.xml"/> > > If these link rel types are acceptable to people, we should probably > define equivelant syntax to be inserted into old Atom feeds to allow the > transition to the new atom as well as define extensions to the various > flavors of RSS. If we can implement this minor extension, we may see many > fewer duplicate feeds being consumed and thus fewer duplicate entries. > Comments? > > bob wyman > > [1] http://www.tbray.org/ongoing/When/200x/2005/04/03/Atom-Now > > From owner-atom-syntax@mail.imc.org Thu Apr 7 14:11:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22173 for ; Thu, 7 Apr 2005 14:11:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37I3RdP096578; Thu, 7 Apr 2005 11:03:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37I3R40096577; Thu, 7 Apr 2005 11:03:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37I3PZL096568 for ; Thu, 7 Apr 2005 11:03:25 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j37I2ZWj028587; Thu, 7 Apr 2005 14:02:42 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CXQ53252 (AUTH bob@wyman.us); Thu, 7 Apr 2005 14:02:23 -0400 (EDT) Message-Id: <200504071802.CXQ53252@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: , Cc: Subject: RE: One reason we have duplicates entries is that we have duplicate feeds... Date: Thu, 7 Apr 2005 14:02:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <42557179.80600@franklinmint.fm> Thread-Index: AcU7mYzoElbWvE90QGOAy9SzsDoncgAAUvWg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > You can point to an alternate feed like this > > Of course, you can't have two alternates with the same media type... Yes, you can point to an alternate. However, all you are doing at that point is establishing equivalence between the two. The "alternate" mechanism doesn't provide you with a way to say which feed is preferred. It also does not allow you to establish that one feed is a sub-set of another (as in the case of "category" feeds.). Establishing equivalence only addresses a part of the problem. If you provide an old-format Atom feed today, will you continue to do so after Atom V1.0 is released? If not, how will automated readers or crawlers discover that it is no longer necessary to seek your old feed or that you have a new feed that replaces it? If you had supported an RSS feed in the past but now decided to switch to an Atom feed, how would the aggregators discover that this was your intention without causing a break in their ability to process your posts? bob wyman -----Original Message----- From: Robert Sayre [mailto:mint@franklinmint.fm] Sent: Thursday, April 07, 2005 1:44 PM To: bob@wyman.us Cc: atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... Bob Wyman wrote: > Unfortunately, while RSS and Atom > both contain mechanisms to identify their "HTML" alternates, there isn't any > clear mechanism available to discover alternate feeds. Without responding to the rest of the message, I'll note that this statement is somewhat inaccurate wrt Atom. You can point to an alternate feed like this Of course, you can't have two alternates with the same media type... Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 7 14:21:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23154 for ; Thu, 7 Apr 2005 14:21:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37ICTiL097851; Thu, 7 Apr 2005 11:12:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37ICTkM097850; Thu, 7 Apr 2005 11:12:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37ICQ4Y097842 for ; Thu, 7 Apr 2005 11:12:28 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-2 ([129.148.9.73]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j37ICPK2023507 for ; Thu, 7 Apr 2005 12:12:26 -0600 (MDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IEL00L0193R4F@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Thu, 07 Apr 2005 14:12:25 -0400 (EDT) Received: from localhost (vpn-129-150-65-228.East.Sun.COM [129.150.65.228]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IEL00LMG98POP@bur-mail1.east.sun.com> for atom-syntax@imc.org; Thu, 07 Apr 2005 14:12:25 -0400 (EDT) Received: from ndw by localhost with local (Exim 4.50) id 1DJbUC-0005wU-6D for atom-syntax@imc.org; Thu, 07 Apr 2005 14:12:20 -0400 X-URL: http://nwalsh.com/ Date: Thu, 07 Apr 2005 14:12:11 -0400 From: Norman Walsh Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... In-reply-to: <200504071734.CXQ40556@ms8.netsolmail.com> To: atom-syntax@imc.org Message-id: <87psx6o3r8.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) References: <200504071734.CXQ40556@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / "Bob Wyman" was heard to say: | A major cause of duplicates in at least some of the existing | services is the fact that bloggers insist on engaging in the apparently | illogical and wasteful practice of publish multiple versions of their fee= ds | and thus duplicates of their entries or items.=20 Illogical and wasteful? I've been doing it for a while as a benefit to my readers. If you only care about DocBook, you can subscribe to http://norman.walsh.name/atom/docbook.xml If you only care about geocaching, you can subscribe to http://norman.walsh.name/atom/geocaching.xml If you want to see all the blather I write, you can subscribe to http://norman.walsh.name/atom/whatsnew.xml Perhaps I shouldn't have done this, and I suppose I could stop, but I have. I had hoped, not having considered the DOS potential, that using the same atom:id in each entry would allow duplicates to be suppressed. I'm disappointed to learn that I've been niave. | One thing that we could do in the short term to reduce the number of | duplicate feeds is to define metadata that would allow feed publishers to | describe the relationships between feeds and describe the content of | different feeds. If, when reading a feed, I could be informed that this f= eed | was a duplicate of another "preferred" feed, I could switch to the prefer= red | feed and stop reading the duplicate. I could use this knowledge to map | subscriptions to the duplicate feeds to their equivalents. This would be | wonderful in the transition from Atom .03 to Atom V1.0... (i.e. if the old | format feed could point to the newer version, we'd all eventually stop | reading the old format feed.) I'd be happy to generate this metadata. | If these link rel types are acceptable to people, we should probably | define equivelant syntax to be inserted into old Atom feeds to allow the | transition to the new atom as well as define extensions to the various | flavors of RSS. If we can implement this minor extension, we may see many | fewer duplicate feeds being consumed and thus fewer duplicate entries. | Comments? +1 Be seeing you, norm =2D-=20 Norman Walsh | CNN is one of the participants in the http://nwalsh.com/ | war. I have a fantasy where Ted Turner | is elected president but refuses | because he doesn't want to give up | power.--Arthur C. Clark --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCVXf7OyltUcwYWjsRAhJ0AJ9qtVKx66usY3cVEf6xcnlZ6il/RgCePq3z tZPwIL6s28R/P/dxnumUSRw= =v3wr -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Apr 7 14:23:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23343 for ; Thu, 7 Apr 2005 14:23:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37IGhIA098261; Thu, 7 Apr 2005 11:16:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37IGhXk098259; Thu, 7 Apr 2005 11:16:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37IGg4J098252 for ; Thu, 7 Apr 2005 11:16:42 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJbYU-00054p-Q8; Thu, 07 Apr 2005 18:16:38 +0000 Message-ID: <42557903.3040000@franklinmint.fm> Date: Thu, 07 Apr 2005 14:16:35 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... References: <200504071802.CXQ53252@ms8.netsolmail.com> In-Reply-To: <200504071802.CXQ53252@ms8.netsolmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Robert Sayre wrote: > >>You can point to an alternate feed like this >> >>Of course, you can't have two alternates with the same media type... > > Yes, you can point to an alternate. However, all you are doing at > that point is establishing equivalence between the two. The "alternate" > mechanism doesn't provide you with a way to say which feed is preferred. It > also does not allow you to establish that one feed is a sub-set of another > (as in the case of "category" feeds.). > Establishing equivalence only addresses a part of the problem. Fully agree. I just wanted to point out that a part of the problem is more solved than your post indicated. > > If you provide an old-format Atom feed today, will you continue to > do so after Atom V1.0 is released? If not, how will automated readers or > crawlers discover that it is no longer necessary to seek your old feed or > that you have a new feed that replaces it? If you had supported an RSS feed > in the past but now decided to switch to an Atom feed, how would the > aggregators discover that this was your intention without causing a break in > their ability to process your posts? I've encountered this situation in the past. Some aggregators continue to poll both locations, though. Not sure why. If they're doing it on purpose, I'm not sure they'd pay attention to feed links either. --------------------------------------------- GET /index.xml HTTP/1.1 Host: www.franklinmint.fm ... HTTP/1.x 301 Moved Permanently Date: Thu, 07 Apr 2005 18:10:30 GMT Location: http://franklinmint.fm/atom.atom ... --------------------------------------------- --------------------------------------------- GET /index.rdf HTTP/1.1 Host: www.franklinmint.fm ... HTTP/1.x 301 Moved Permanently Date: Thu, 07 Apr 2005 18:10:36 GMT Location: http://franklinmint.fm/atom.atom ... --------------------------------------------- Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 7 14:37:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24756 for ; Thu, 7 Apr 2005 14:37:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37ITeAk099365; Thu, 7 Apr 2005 11:29:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37ITeIc099364; Thu, 7 Apr 2005 11:29:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37ITdog099358 for ; Thu, 7 Apr 2005 11:29:39 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j37ITYeH020475; Thu, 7 Apr 2005 14:29:37 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CXQ65510 (AUTH bob@wyman.us); Thu, 7 Apr 2005 14:29:31 -0400 (EDT) Message-Id: <200504071829.CXQ65510@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: , Cc: Subject: RE: One reason we have duplicates entries is that we have duplicate feeds... Date: Thu, 7 Apr 2005 14:29:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <42557903.3040000@franklinmint.fm> Thread-Index: AcU7nh3B7nbZaYWESoipf5EnpYeaxQAAGEbQ Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: >> Establishing equivalence only addresses a part of the problem. > Fully agree. I just wanted to point out that a part of the problem is > more solved than your post indicated. My apologies if I made the situation sound more dire than it is. However, even with the "alternate" we've still got a pretty big problem. > HTTP/1.x 301 Moved Permanently Another partial solution... Useful in some situations, but relying on it prevents anticipating change and thus may result in some data loss. Also, a change like this requires access to the web server configuration in many installations and hosted users can't always get such access. > [When there are multiple feeds] Some aggregators continue to poll both > locations, though. Not sure why. > If they're doing it on purpose, I'm not sure they'd pay attention to > feed links either. The automated aggregators are stuck polling all feeds in many cases because: 1. They can't determine the equivelance between feeds without explicit statements from the publisher. 2. Even if equivalence is known, we can't know which feed is "authoritative" or if one feed will be deleted in favor of the other. Thus, we've got to read both to ensure that we are reading which ever one is more long-lived. 3. We have to read all feeds since users like to be able to subscribe to feeds using file names or masks on file names... If we don't read all feeds, we will incorrectly fail to deliver to the user content that we have available to us. > I'm not sure they'd pay attention to feed links either I *guarantee* you that if we had an accepted way to address this in feeds, PubSub *would* pay careful attention to it. bob wyman From owner-atom-syntax@mail.imc.org Thu Apr 7 14:56:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26893 for ; Thu, 7 Apr 2005 14:56:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Ingtn001506; Thu, 7 Apr 2005 11:49:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37IngAg001505; Thu, 7 Apr 2005 11:49:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j37Infvw001491 for ; Thu, 7 Apr 2005 11:49:41 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 07 Apr 2005 18:49:34 -0000 Received: from xdsl-213-196-250-81.netcologne.de (EHLO klangraum) [213.196.250.81] by mail.gmx.net (mp001) with SMTP; 07 Apr 2005 20:49:34 +0200 X-Authenticated: #163624 Date: Thu, 7 Apr 2005 20:52:07 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... Message-ID: <20050407185207.GA25835@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <200504071734.CXQ40556@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504071734.CXQ40556@ms8.netsolmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Bob Wyman [2005-04-07 19:45]: > I.e. if I didn't like something you published, I would simply > publish something in my blog that had the same atom:id as > something you had published. PubSub and other synthetic feed > producers would then flush your post from the system and > replace it with my post... > > [...] > > If, when reading a feed, I could be informed that this feed was > a duplicate of another "preferred" feed, I could switch to the > preferred feed and stop reading the duplicate. I could use this > knowledge to map subscriptions to the duplicate feeds to their > equivalents. Together, to me, these suggest that atom:entry/atom:id should be conisdered unique only with respect to the originating feed, or, per the proposal, with with respect to the originating feed and all of the feeds it points to. Correct? Under the assumption that my understanding is correct, then the proposition is insufficient. It works for aggregating/ republishing services that consume feeds from original producers, such as PubSub. But it breaks down for the aggregate feeds published by third parties. Imagine someone using Bloglines subscribes to PlanetFoo and PlanetBar, both of which republish content from feed Baz. Now how does Bloglines assure that the duplicate Baz entries it receives from PlanetFoo and PlanetBar, neither of which are its original producers but (in absence of malicious intent) reproduce content from the same source, do indeed originate from the same source? If look at more convoluted examples, it fast turns into web of trust territory... Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Thu Apr 7 14:57:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26923 for ; Thu, 7 Apr 2005 14:57:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37ImIYX001318; Thu, 7 Apr 2005 11:48:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37ImInr001317; Thu, 7 Apr 2005 11:48:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37ImHBN001310 for ; Thu, 7 Apr 2005 11:48:17 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j37ImGeD000904 for ; Thu, 7 Apr 2005 14:48:17 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CXQ74688 (AUTH bob@wyman.us); Thu, 7 Apr 2005 14:48:14 -0400 (EDT) Message-Id: <200504071848.CXQ74688@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: Subject: Spaces supports slash:comments. Result = Duplicates Galore! Date: Thu, 7 Apr 2005 14:48:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcU7olZWfoHpE4G5Sqyl+kKaFb/eFg== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j37ImIBN001311 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Spaces.msn.com recently announced support for "slash:comments," an element which shows how many comments an RSS item has associated with it. As Dare Obasanjo explains[1]: "Another cool RSS enhancement is that the number of comments on each post is now provided using the slash:comments elements. Now users of aggregators like RSS Bandit can track the comment counts on various posts on a space. I've been wanting that since last year." Of course, the side effect of this change is that any aggregator that uses an MD5-like approach to detect changes will now think that an entry has been updated every time a new comment is made. This may or may not be what is desired by consumers of feeds... In any case, there are now millions of blogs whose entries are changed every time anyone comments on them. Should aggregators ignore changes that are limited to the "slash:comments" element? If so, are there other elements that should be ignored? Now, Spaces only publishes RSS feeds... However, if similar atom extensions were to be defined, the problem would appear with Atom feeds as well. bob wyman [1] http://spaces.msn.com/members/carnage4life/Blog/cns%211piiOwAp2SJRIfUfD95CnR Lw%21430.entry From owner-atom-syntax@mail.imc.org Thu Apr 7 14:58:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26998 for ; Thu, 7 Apr 2005 14:58:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Iq9Cx001817; Thu, 7 Apr 2005 11:52:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37Iq9GH001816; Thu, 7 Apr 2005 11:52:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Iq7TO001761 for ; Thu, 7 Apr 2005 11:52:07 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.69.81]) by smtp.cegetel.net (Postfix) with ESMTP id 2C23A67B55; Thu, 7 Apr 2005 20:52:01 +0200 (CEST) Message-ID: <4255814C.5060602@cegetel.net> Date: Thu, 07 Apr 2005 20:51:56 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: bob@wyman.us Cc: mint@franklinmint.fm, atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... References: <200504071802.CXQ53252@ms8.netsolmail.com> In-Reply-To: <200504071802.CXQ53252@ms8.netsolmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Robert Sayre wrote: > >>You can point to an alternate feed like this >> >>Of course, you can't have two alternates with the same media type... > > Yes, you can point to an alternate. However, all you are doing at > that point is establishing equivalence between the two. The "alternate" > mechanism doesn't provide you with a way to say which feed is preferred. Well, if you publish Atom 1.0, RSS 1.0 and RSS 2.0 feeds, they should all be equivalent. Which is "preferred" is on the end-user's hands. Say you publish an interview as text/plain, text/html and application/msword. Each end-user will choose his/her preferred version. What you can do to indicate your preferred version (otherwise putting up some web page that links to each version and tell the end-user which one you prefer) is to put them all at the same location (URI) and use content negotiation, associating q-values on the server side; but client provided q-values and accepted media types will be used to serve the *client's* preferred version anyway. > It also does not allow you to establish that one feed is a sub-set of another > (as in the case of "category" feeds.). Well, actually yes: use atom:source in your entries. Either you consider "category" feeds to be the "primary feeds" and use atom:source in the "whole site" feed (and you'll have to choose a "primary category" as well for entries belonging to two or more categories); or you treat the "whole site" feed as the primary feed and put atom:source elements in your "category" feeds. However, I'm +1 on defining some new kind of link@rel. They don't have to be put in the spec, they could only be some "generally used values", defined and encouraged by the Atom WG without begin in the Atom 1.0 spec (and maybe be added to a future Atom version) > If you provide an old-format Atom feed today, will you continue to > do so after Atom V1.0 is released? If not, how will automated readers or > crawlers discover that it is no longer necessary to seek your old feed or > that you have a new feed that replaces it? If you had supported an RSS feed > in the past but now decided to switch to an Atom feed, how would the > aggregators discover that this was your intention without causing a break in > their ability to process your posts? If you keep the same URI, I think there won't be much problem, many readers/aggregators handling several syndication formats. You might eventually continue to serve RSS as well and use content negotiation for a while, waiting for the Atom 1.0 format to be widely used. If you change the URI (say you used to have http://example.net/myfeed.rss and now move to http://example.net/myfeed.atom), send an HTTP "301 Moved Permanently" status to redirect clients to the new URI. Anyway, if you stop delivering some content in some media type, you can't expect not to "cause a break in their ability to process your [content]". So in a few words: +1 for what you propose, not necessarily to be added to the Atom spec, but the problem you pointed out is not /that/ grave. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Apr 7 14:58:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27021 for ; Thu, 7 Apr 2005 14:58:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Io9xR001564; Thu, 7 Apr 2005 11:50:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37Io9gB001563; Thu, 7 Apr 2005 11:50:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Io8Ze001557 for ; Thu, 7 Apr 2005 11:50:08 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j37Io7K2021055 for ; Thu, 7 Apr 2005 12:50:07 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEL00ENNAZJEA@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 07 Apr 2005 12:50:07 -0600 (MDT) Received: from [192.168.102.100] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEL005U8AZIUN@mail.sun.net> for atom-syntax@imc.org; Thu, 07 Apr 2005 12:50:07 -0600 (MDT) Date: Thu, 07 Apr 2005 11:50:38 -0700 From: Tim Bray Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... In-reply-to: <200504071734.CXQ40556@ms8.netsolmail.com> To: bob@wyman.us Cc: atom-syntax@imc.org Message-id: <7374088810e564759f8d572481348f6f@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200504071734.CXQ40556@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 7, 2005, at 10:34 AM, Bob Wyman wrote: > Tim suggests that aggregators should be able to rely simply on > atom:id to detect duplicates. However, as has often been pointed out, > applying this rule in an intermediary like PubSub would simply make > PubSub a > marvelously efficient tool for denial of service attacks. I.e. if I > didn't > like something you published, I would simply publish something in my > blog > that had the same atom:id as something you had published. PubSub and > other > synthetic feed producers would then flush your post from the system and > replace it with my post... Not good -- and not avoidable given the > current > loose rules for defining instances of atom:id. Yes. Mea culpa; somehow I'd missed this. Would the following work: 1. A new feed-level element , any number allowed. E.g. http://www.tbray.org/ongoing/ http://www.tbray.org/ http://tbray.org/ http://www.textuality.com; Thu, 7 Apr 2005 15:06:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Iwv8p002724; Thu, 7 Apr 2005 11:58:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37Iwvnw002723; Thu, 7 Apr 2005 11:58:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37IwuQo002702 for ; Thu, 7 Apr 2005 11:58:56 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j37Ivfs2006502; Thu, 7 Apr 2005 19:57:51 +0100 (BST) In-Reply-To: <200504071829.CXQ65510@ms8.netsolmail.com> References: <200504071829.CXQ65510@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3ca86f88411c33fff9ce2ef1a1702302@mac.com> Content-Transfer-Encoding: 7bit Cc: "Atom-Syntax Syntax'" From: Graham Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... Date: Thu, 7 Apr 2005 19:57:42 +0100 To: bob@wyman.us X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I don't think this is within the scope of Atom or any other spec. If you want to differentiate your others, why not invest some time in a decent duplicate detection algorithm like Google did? This is your problem. Graham On 7 Apr 2005, at 7:29 pm, Bob Wyman wrote: > > Robert Sayre wrote: >>> Establishing equivalence only addresses a part of the problem. >> Fully agree. I just wanted to point out that a part of the problem is >> more solved than your post indicated. > My apologies if I made the situation sound more dire than it is. > However, even with the "alternate" we've still got a pretty big > problem. > >> HTTP/1.x 301 Moved Permanently > Another partial solution... Useful in some situations, but relying > on it prevents anticipating change and thus may result in some data > loss. > Also, a change like this requires access to the web server > configuration in > many installations and hosted users can't always get such access. > >> [When there are multiple feeds] Some aggregators continue to poll both >> locations, though. Not sure why. >> If they're doing it on purpose, I'm not sure they'd pay attention to >> feed links either. > The automated aggregators are stuck polling all feeds in many cases > because: > 1. They can't determine the equivelance between feeds without > explicit statements from the publisher. > 2. Even if equivalence is known, we can't know which feed is > "authoritative" or if one feed will be deleted in favor of the other. > Thus, > we've got to read both to ensure that we are reading which ever one is > more > long-lived. > 3. We have to read all feeds since users like to be able to > subscribe to feeds using file names or masks on file names... If we > don't > read all feeds, we will incorrectly fail to deliver to the user > content that > we have available to us. > >> I'm not sure they'd pay attention to feed links either > I *guarantee* you that if we had an accepted way to address this in > feeds, PubSub *would* pay careful attention to it. > > bob wyman > From owner-atom-syntax@mail.imc.org Thu Apr 7 15:11:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28578 for ; Thu, 7 Apr 2005 15:11:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37J6is0003550; Thu, 7 Apr 2005 12:06:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37J6iCg003549; Thu, 7 Apr 2005 12:06:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37J6ivZ003539 for ; Thu, 7 Apr 2005 12:06:44 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id ED7FAF3; Thu, 7 Apr 2005 12:06:38 -0700 (PDT) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j37J6Xng012329; Thu, 7 Apr 2005 12:06:33 -0700 (PDT) Date: Thu, 07 Apr 2005 12:10:18 -0700 From: Walter Underwood To: bob@wyman.us, atom-syntax@imc.org Subject: Re: Spaces supports slash:comments. Result = Duplicates Galore! Message-ID: <1ADB790C2B8B9502FE024706@diva.verity.com> In-Reply-To: <200504071848.CXQ74688@ms8.netsolmail.com> References: <200504071848.CXQ74688@ms8.netsolmail.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j37J6ivZ003544 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit One way to look at this is to define what parts are local content as opposed to caches of remote, and base the Etag or other hash on that. I still think we should address caching in Atom 1.0. This would have been part of that. Scaling is an essential thing for syndication, and caching is the best known way to scale. wunder --On Thursday, April 07, 2005 02:48:07 PM -0400 Bob Wyman wrote: > > Spaces.msn.com recently announced support for "slash:comments," an > element which shows how many comments an RSS item has associated with it. > As Dare Obasanjo explains[1]: > > "Another cool RSS enhancement is that the number of comments on > each post is now provided using the slash:comments elements. Now > users of aggregators like RSS Bandit can track the comment counts on > various posts on a space. I've been wanting that since last year." > > Of course, the side effect of this change is that any aggregator > that uses an MD5-like approach to detect changes will now think that an > entry has been updated every time a new comment is made. This may or may not > be what is desired by consumers of feeds... In any case, there are now > millions of blogs whose entries are changed every time anyone comments on > them. Should aggregators ignore changes that are limited to the > "slash:comments" element? If so, are there other elements that should be > ignored? > Now, Spaces only publishes RSS feeds... However, if similar atom > extensions were to be defined, the problem would appear with Atom feeds as > well. > > bob wyman > > [1] > http://spaces.msn.com/members/carnage4life/Blog/cns%211piiOwAp2SJRIfUfD95CnR > Lw%21430.entry > > > > -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Thu Apr 7 15:14:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28867 for ; Thu, 7 Apr 2005 15:14:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37J756w003597; Thu, 7 Apr 2005 12:07:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37J75fT003596; Thu, 7 Apr 2005 12:07:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37J74FQ003578 for ; Thu, 7 Apr 2005 12:07:05 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j37J64Jq008419; Thu, 7 Apr 2005 20:06:13 +0100 (BST) In-Reply-To: <200504071848.CXQ74688@ms8.netsolmail.com> References: <200504071848.CXQ74688@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0e6501d29552981ccbdd9a4351414db8@mac.com> Content-Transfer-Encoding: 7bit Cc: "Atom-Syntax Syntax'" From: Graham Subject: Re: Spaces supports slash:comments. Result = Duplicates Galore! Date: Thu, 7 Apr 2005 20:06:05 +0100 To: bob@wyman.us X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7 Apr 2005, at 7:48 pm, Bob Wyman wrote: > Of course, the side effect of this change is that any aggregator > that uses an MD5-like approach to detect changes will now think that an > entry has been updated every time a new comment is made. This may or > may not > be what is desired by consumers of feeds... In any case, there are now > millions of blogs whose entries are changed every time anyone comments > on > them. Should aggregators ignore changes that are limited to the > "slash:comments" element? If so, are there other elements that should > be > ignored? Not that I have any data, but I don't seriously believe any aggregator that uses the content hash approach would survive very long in the market place without being buried under user complaints. Most (the one's I know of) either use identifiers or failing that some subset of the elements. Shrook uses an adaptive subset that means that if one element is unreliable it uses the others. Graham From owner-atom-syntax@mail.imc.org Thu Apr 7 15:20:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29595 for ; Thu, 7 Apr 2005 15:20:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37JBqoj004183; Thu, 7 Apr 2005 12:11:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37JBqnc004182; Thu, 7 Apr 2005 12:11:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37JBqwC004175 for ; Thu, 7 Apr 2005 12:11:52 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.9]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJcPq-0005gP-FS; Thu, 07 Apr 2005 19:11:46 +0000 Message-ID: <425585EF.8050600@franklinmint.fm> Date: Thu, 07 Apr 2005 15:11:43 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: bob@wyman.us, "Atom-Syntax Syntax'" Subject: Re: Spaces supports slash:comments. Result = Duplicates Galore! References: <200504071848.CXQ74688@ms8.netsolmail.com> <0e6501d29552981ccbdd9a4351414db8@mac.com> In-Reply-To: <0e6501d29552981ccbdd9a4351414db8@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > On 7 Apr 2005, at 7:48 pm, Bob Wyman wrote: > >> Of course, the side effect of this change is that any aggregator >> that uses an MD5-like approach to detect changes will now think that an >> entry has been updated every time a new comment is made. This may or >> may not >> be what is desired by consumers of feeds... In any case, there are now >> millions of blogs whose entries are changed every time anyone comments on >> them. Should aggregators ignore changes that are limited to the >> "slash:comments" element? If so, are there other elements that should be >> ignored? > > > Not that I have any data, but I don't seriously believe any aggregator > that uses the content hash approach would survive very long in the > market place without being buried under user complaints. Most (the one's > I know of) either use identifiers or failing that some subset of the > elements. Shrook uses an adaptive subset that means that if one element > is unreliable it uses the others. Mozilla Thunderbird's approach will be similar when the relevant bugs are closed. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 7 15:21:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29700 for ; Thu, 7 Apr 2005 15:21:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37JFxhh004736; Thu, 7 Apr 2005 12:15:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37JFxh9004735; Thu, 7 Apr 2005 12:15:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37JFwid004697 for ; Thu, 7 Apr 2005 12:15:58 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.69.81]) by smtp.cegetel.net (Postfix) with ESMTP id 36CD83815A; Thu, 7 Apr 2005 21:15:45 +0200 (CEST) Message-ID: <425586E1.4040204@cegetel.net> Date: Thu, 07 Apr 2005 21:15:45 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Tim Bray Cc: bob@wyman.us, atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... References: <200504071734.CXQ40556@ms8.netsolmail.com> <7374088810e564759f8d572481348f6f@sun.com> In-Reply-To: <7374088810e564759f8d572481348f6f@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > 1. A new feed-level element , any number allowed. > E.g. > > > http://www.tbray.org/ongoing/ > http://www.tbray.org/ > http://tbray.org/ > http://www.textuality.com; Thu, 7 Apr 2005 15:30:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37JNnNU005651; Thu, 7 Apr 2005 12:23:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37JNn3d005650; Thu, 7 Apr 2005 12:23:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37JNmD7005640 for ; Thu, 7 Apr 2005 12:23:48 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j37JNPTh003532; Thu, 7 Apr 2005 15:23:36 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CXQ90842 (AUTH bob@wyman.us); Thu, 7 Apr 2005 15:23:18 -0400 (EDT) Message-Id: <200504071923.CXQ90842@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Graham'" , Cc: "'Atom-Syntax Syntax''" Subject: RE: Spaces supports slash:comments. Result = Duplicates Galore! Date: Thu, 7 Apr 2005 15:23:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <0e6501d29552981ccbdd9a4351414db8@mac.com> Thread-Index: AcU7pQbSXTS96uhRSGisNCfBBbhgoAAAXjsQ Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > I don't seriously believe any aggregator that uses the content hash > approach would survive very long in the market place without being > buried under user complaints. Most (the one's I know of) either use > identifiers or failing that some subset of the elements. The "identifier-based" approach works wonderfully for a single user aggregator which has a "feed" focus as most personal aggregators do today. However, as pointed out elsewhere, the identifier-based approaches don't work in cross-feed duplicate detection because of the ease with which denial of service attacks can be launched. If a subset of elements is to be used in duplicate detection, what is that subset? Can/Should this subset be commonly known? It seems to me that it is important enough to the atom-ecosphere that it might even make sense to have it in the spec as an important interoperability note. i.e. "Entries will be considered duplicates if...." > Shrook uses an adaptive subset that means that if one element is > unreliable it uses the others. Can you describe your algorithm? What do you consider "unreliable" to mean? bob wyman From owner-atom-syntax@mail.imc.org Thu Apr 7 15:46:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01484 for ; Thu, 7 Apr 2005 15:46:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37JbI7L007276; Thu, 7 Apr 2005 12:37:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37JbIeN007275; Thu, 7 Apr 2005 12:37:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37JbI5t007269 for ; Thu, 7 Apr 2005 12:37:18 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j37Jawmq012705; Thu, 7 Apr 2005 15:37:05 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CXQ96861 (AUTH bob@wyman.us); Thu, 7 Apr 2005 15:36:56 -0400 (EDT) Message-Id: <200504071936.CXQ96861@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Thomas Broyer'" , "'Tim Bray'" Cc: , Subject: RE: One reason we have duplicates entries is that we have duplicate feeds... Date: Thu, 7 Apr 2005 15:36:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <425586E1.4040204@cegetel.net> Thread-Index: AcU7p5XgWciQ6xUbRpOpo4YZP3G38QAAGnSw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thomas Broyer wrote: > When PlanetBar and PlanetFoo republish a feed from Baz, they should > "move" the entry metadata into an atom:source element. This is actually what we do at PubSub today. You may not be aware that the atom:source element is modeled on the ps:source-feed element that we have been publishing in our Atom feeds since last June. Into every entry we publish at PubSub, we put in something like the following: <![CDATA[Scoble's Link Blog]]> The text/html alternate and the title are taken from the feed element of the source feed. The text/xml link indicates the URI of the feed we read (this isn't normally in the Feed metadata...). (Yes, I know it probably should be "application/xml" and would ideally be specific as to type since we know it is RSS or Atom, etc. But, that's not the point of this discussion.). bob wyman From owner-atom-syntax@mail.imc.org Thu Apr 7 15:50:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01859 for ; Thu, 7 Apr 2005 15:50:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Jhi94007761; Thu, 7 Apr 2005 12:43:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37Jhikl007760; Thu, 7 Apr 2005 12:43:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j37JhhW7007750 for ; Thu, 7 Apr 2005 12:43:44 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 70226 messnum 5762452 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 7 Apr 2005 19:43:37 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail12.svc.cra.dublin.eircom.net (qp 70226) with SMTP; 7 Apr 2005 19:43:37 -0000 Message-ID: <42558D67.3050700@dehora.net> Date: Thu, 07 Apr 2005 20:43:35 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Broyer CC: Tim Bray , bob@wyman.us, atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... References: <200504071734.CXQ40556@ms8.netsolmail.com> <7374088810e564759f8d572481348f6f@sun.com> <425586E1.4040204@cegetel.net> In-Reply-To: <425586E1.4040204@cegetel.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thomas Broyer wrote: > > Tim Bray wrote: > >> 1. A new feed-level element , any number >> allowed. E.g. >> >> >> http://www.tbray.org/ongoing/ >> http://www.tbray.org/ >> http://tbray.org/ >> http://www.textuality.com > > Although this doesn't solve the DOS potential, I'd rather go for a new > atom:source child element indicating the source feed's Id or URI. When > PlanetBar and PlanetFoo republish a feed from Baz, they should "move" > the entry metadata into an atom:source element. One step further: how does that work for PlanetPlanet? cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 7 16:26:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04810 for ; Thu, 7 Apr 2005 16:26:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37KHjt0011901; Thu, 7 Apr 2005 13:17:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37KHjeR011900; Thu, 7 Apr 2005 13:17:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37KHieI011891 for ; Thu, 7 Apr 2005 13:17:45 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j37KHfTl001970; Thu, 7 Apr 2005 16:17:43 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CXR16597 (AUTH bob@wyman.us); Thu, 7 Apr 2005 16:17:39 -0400 (EDT) Message-Id: <200504072017.CXR16597@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: , Cc: Subject: RE: One reason we have duplicates entries is that we have duplicate feeds... Date: Thu, 7 Apr 2005 16:17:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <7374088810e564759f8d572481348f6f@sun.com> Thread-Index: AcU7oq/LTFKom9exTjOPbfoRnyaEWAACm9aQ Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: >Would the following work: >1. A new feed-level element , any number allowed. > > http://www.tbray.org/ongoing/ > http://www.tbray.org/ > http://tbray.org/ I don't like this. Hopefully, I can explain why. The reason is a bit subtle... Tim's proposal relies on a feed "empowering" one or more other feeds. He allows a feed to say: "Any of these other feeds are allowed to override me." The proposal I made relies on a feed making statements only about itself. In my proposal, a feed can only say: "I contain copies of these other feeds. I am a secondary feed." Personally, I think we're safer if we only allow feeds to speak about themselves. The moment we start down the road of granting rights, we're heading towards quicksand. I should also say that I like the idea of a feed subordinating itself to another in that we would inevitably get from that the idea of a "primary" feed. i.e. The primary is that feed which defers to no other feed. A side benefit of having "primary feeds" would be that people would be more likely to do things like include full "category" data in the entries they publish rather than publishing entries into specialized feeds as the way to indicate "category." bob wyman From owner-atom-syntax@mail.imc.org Thu Apr 7 16:38:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05841 for ; Thu, 7 Apr 2005 16:38:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37KWeUx013560; Thu, 7 Apr 2005 13:32:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37KWekW013559; Thu, 7 Apr 2005 13:32:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37KWedH013552 for ; Thu, 7 Apr 2005 13:32:40 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j37KWVTh009301; Thu, 7 Apr 2005 16:32:32 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CXR22826 (AUTH bob@wyman.us); Thu, 7 Apr 2005 16:32:29 -0400 (EDT) Message-Id: <200504072032.CXR22826@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'A. Pagaltzis'" , Subject: RE: One reason we have duplicates entries is that we have duplicate feeds... Date: Thu, 7 Apr 2005 16:32:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20050407185207.GA25835@klangraum> Thread-Index: AcU7pJT5mYXDas9ISbuSEcdVZUwk8wAClRYA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A. Pagaltzis wrote: > But it breaks down for the aggregate feeds published by third parties. > If look at more convoluted examples, it fast turns into web of > trust territory... You are correct -- with one caveat. If entries are signed, which Atom supports, you have a mechanism that allows you to trust statements that copies of entries make about their source feeds. This is precisely why we at PubSub so strongly supported the introduction of digital signatures into Atom and why we consider this to be one of the really significant advantages of Atom over existing RSS definitions. (Yes, I realize that no one signs entries. But, that is a problem to be dealt with later...) If an entry is not signed, or if you don't have the means to validate the signature, then you are stuck simply trusting the third parties from whom you receive copies of entries. Yes, we've entered into "web of trust territory." This explains why I have in the past argued that synthetic or aggregate feeds should be explicitly tagged as such or that we should *require* that source data be inserted into all copies of entries. (I really do not like the "May" and "Should" words concerning atom:source in the current draft.) For a service like PubSub's, what we'll probably do is consider any entry copies that we discover to be somewhat equivalent to "pings." i.e. if we see something with a "foreign" source, we'll probably want to check that source to validate the copied entry before we republish it. (Note: I'm not sure what we'll do if the entry has been purged from the source-feed... Perhaps, we could flag it as "questionable"???) I don't however, expect personal aggregators to do this and I expect that those who take feeds from us will learn that they can trust us to properly validate things. Thus, they won't need to be as rigorous as we must be. In the absence of signatures, you have no choice but to trust your intermediaries. There is no design that can change that. We're going to be working hard to make sure you can trust PubSub. bob wyman From owner-atom-syntax@mail.imc.org Thu Apr 7 16:56:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07241 for ; Thu, 7 Apr 2005 16:56:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37KklVw014571; Thu, 7 Apr 2005 13:46:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37Kklxk014570; Thu, 7 Apr 2005 13:46:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j37KkjIN014556 for ; Thu, 7 Apr 2005 13:46:45 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 07 Apr 2005 20:46:39 -0000 Received: from xdsl-213-196-252-197.netcologne.de (EHLO klangraum) [213.196.252.197] by mail.gmx.net (mp016) with SMTP; 07 Apr 2005 22:46:39 +0200 X-Authenticated: #163624 Date: Thu, 7 Apr 2005 22:49:13 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Spaces supports slash:comments. Result = Duplicates Galore! Message-ID: <20050407204913.GA26197@klangraum> Mail-Followup-To: Atom Syntax References: <0e6501d29552981ccbdd9a4351414db8@mac.com> <200504071923.CXQ90842@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200504071923.CXQ90842@ms8.netsolmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Bob Wyman [2005-04-07 21:30]: > Can/Should this subset be commonly known? It seems to me that > it is important enough to the atom-ecosphere that it might even > make sense to have it in the spec as an important > interoperability note. i.e. "Entries will be considered > duplicates if...." Yes, absolutely, implementors should be made aware of such issues. I don’t know if it is in the scope of the Atom format to specify normative rules for when to consider entries duplicates – and more importantly, when not to –, though. F.ex, entries maliciously published with someone else’s entry ID will not actually constitute a DOS attack for consumers whose aggregator maintains a history of previously seen versions of an entry. Other approaches may also form. Generally, practice will probably lead implementors to pick among various approaches the one best suited to their respective needs. I don’t believe we can forsee all of these, so let’s not try to. The Atom format should specify hooks (such as the atom:source subelement Thomas suggested, possibly?) which would allow trust models or other coping mechanisms to be implemented, but leave their precise nature to the discreetion of implementors after bringing the potential problems to attention. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Thu Apr 7 17:16:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09060 for ; Thu, 7 Apr 2005 17:16:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37L88Mw016731; Thu, 7 Apr 2005 14:08:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37L88IW016730; Thu, 7 Apr 2005 14:08:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37L86XM016715 for ; Thu, 7 Apr 2005 14:08:07 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.69.81]) by smtp.cegetel.net (Postfix) with ESMTP id 5AA0867334; Thu, 7 Apr 2005 23:08:00 +0200 (CEST) Message-ID: <4255A131.3070102@cegetel.net> Date: Thu, 07 Apr 2005 23:08:01 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Cc: Tim Bray , bob@wyman.us, atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... References: <200504071734.CXQ40556@ms8.netsolmail.com> <7374088810e564759f8d572481348f6f@sun.com> <425586E1.4040204@cegetel.net> <42558D67.3050700@dehora.net> In-Reply-To: <42558D67.3050700@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > Thomas Broyer wrote: >> Although this doesn't solve the DOS potential, I'd rather go for a new >> atom:source child element indicating the source feed's Id or URI. When >> PlanetBar and PlanetFoo republish a feed from Baz, they should "move" >> the entry metadata into an atom:source element. > > > One step further: how does that work for PlanetPlanet? As I told in the phrase you stripped out? >> They'll then also add that new element (atom:feedid ? doh, yet another >> two-word name) When PubSub republish the entry, it preserves the >> atom:source content as-is, preserving the source feed's Id at the >> same time. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Apr 7 17:18:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09390 for ; Thu, 7 Apr 2005 17:18:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37L9oF7016914; Thu, 7 Apr 2005 14:09:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37L9oLT016913; Thu, 7 Apr 2005 14:09:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j37L9mMa016887 for ; Thu, 7 Apr 2005 14:09:49 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 07 Apr 2005 21:09:43 -0000 Received: from xdsl-213-196-252-197.netcologne.de (EHLO klangraum) [213.196.252.197] by mail.gmx.net (mp014) with SMTP; 07 Apr 2005 23:09:43 +0200 X-Authenticated: #163624 Date: Thu, 7 Apr 2005 23:12:17 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: Spaces supports slash:comments. Result = Duplicates Galore! Message-ID: <20050407211217.GB26197@klangraum> Mail-Followup-To: Atom Syntax References: <0e6501d29552981ccbdd9a4351414db8@mac.com> <200504071923.CXQ90842@ms8.netsolmail.com> <20050407204913.GA26197@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050407204913.GA26197@klangraum> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * A. Pagaltzis [2005-04-07 22:55]: > F.ex, entries maliciously published with someone else’s entry > ID will not actually constitute a DOS attack for consumers > whose aggregator maintains a history of previously seen > versions of an entry. Sorry, wrong thread. I have been hesitating to post (after my first posts to the list missed the topic as well) because I’m constantly tired lately and my concentration is shot. Ugh. As concerns the thread I was addressing, I still stand by my argument about the scope of the Atom format, though. Embarrassed, -- Aristotle From owner-atom-syntax@mail.imc.org Thu Apr 7 17:20:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09592 for ; Thu, 7 Apr 2005 17:20:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37L9XHI016875; Thu, 7 Apr 2005 14:09:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37L9XF0016874; Thu, 7 Apr 2005 14:09:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37L9Xd9016868 for ; Thu, 7 Apr 2005 14:09:33 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j37LBRFR024409; Thu, 7 Apr 2005 17:11:31 -0400 Message-ID: <4255A185.4030608@intertwingly.net> Date: Thu, 07 Apr 2005 17:09:25 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Atom Syntax Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> In-Reply-To: <42553A72.2090207@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > Sam Ruby wrote: > >> At this point, small surgical changes to address specific concerns may >> (or may not) be acceptable. Wholesale changes with little rationale >> are less likely to be so. > > Well, who really cares anyway. I'll get the draft ready. Nobody propose > any 'wholesale changes' in the meantime, OK? I don't know about you, but I do care. Whether it is for accessibility, or for general usability, I want to ensure that every entry has a textual, non-remote component to it. You have made a number of noises that it is your intent to use last call as your opportunity to challenge the working group to revisit this. Please don't. If you truly are concerned about co-occurrence constraints, recast the grammar so that content and summary are the same element, possibly with multipart alternatives. See if you can come up with a less hideous syntax than either 0.3 or -07. Make this element mandatory, and I'm happy. If your real goal, however, is to make textual non-remote information optional, please don't. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Apr 7 17:21:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09621 for ; Thu, 7 Apr 2005 17:21:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LDjgF017351; Thu, 7 Apr 2005 14:13:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37LDj8p017349; Thu, 7 Apr 2005 14:13:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LDh6Y017332 for ; Thu, 7 Apr 2005 14:13:43 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta07-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050407211332.VMAO928.mta08-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com> for ; Thu, 7 Apr 2005 22:13:32 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta07-winn.mailhost.ntl.com with ESMTP id <20050407211332.LLML10174.aamta07-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com> for ; Thu, 7 Apr 2005 22:13:32 +0100 Date: Thu, 7 Apr 2005 22:13:29 +0100 From: David Powell X-Mailer: The Bat! (v3.0.9.13 Return) Professional X-Priority: 3 (Normal) Message-ID: <67946152.20050407221329@djpowell.net> To: atom-syntax@imc.org Subject: Required elements for atom:source MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit According to the RelaxNG: > atomSource = > element atom:source { > atomCommonAttributes, > (atomAuthor? > & atomCategory* > & atomContributor* > & atomCopyright? > & atomGenerator? > & atomIcon? > & atomId? > & atomImage? > & atomLink+ > & atomSubtitle? > & atomTitle > & atomUpdated > & extensionElement*) ... atom:title and atom:updated are required for atom:source. Is this a typo? I'd assume that no elements should be required for atom:source, on the principle that anything that you can provide is better than nothing. -- Dave From owner-atom-syntax@mail.imc.org Thu Apr 7 17:28:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10159 for ; Thu, 7 Apr 2005 17:28:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LIBnp017926; Thu, 7 Apr 2005 14:18:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37LIBDw017925; Thu, 7 Apr 2005 14:18:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j37LI95X017896 for ; Thu, 7 Apr 2005 14:18:10 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 07 Apr 2005 21:18:04 -0000 Received: from xdsl-213-196-252-197.netcologne.de (EHLO klangraum) [213.196.252.197] by mail.gmx.net (mp003) with SMTP; 07 Apr 2005 23:18:04 +0200 X-Authenticated: #163624 Date: Thu, 7 Apr 2005 23:20:37 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... Message-ID: <20050407212037.GC26197@klangraum> Mail-Followup-To: Atom Syntax References: <20050407185207.GA25835@klangraum> <200504072032.CXR22826@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200504072032.CXR22826@ms8.netsolmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Bob Wyman [2005-04-07 22:40]: > A. Pagaltzis wrote: > > But it breaks down for the aggregate feeds published by third > > parties. If look at more convoluted examples, it fast turns > > into web of trust territory... > You are correct -- with one caveat. If entries are signed, Yes, of course. > This explains why I have in the past argued that synthetic or > aggregate feeds should be explicitly tagged as such or that we > should *require* that source data be inserted into all copies > of entries. And it is a good argument to make. > i.e. if we see something with a "foreign" source, we'll > probably want to check that source to validate the copied entry > before we republish it. Yes, that’s the only sane approach I can think of, as well. > (Note: I'm not sure what we'll do if the entry has been purged > from the source-feed... Perhaps, we could flag it as > "questionable"???) Certainly questionable, unless there are indicators that the foreign source is trustworthy. After all – assuming a reasonably short timespan between each party polling the others –, if you can’t find the updated entry in the source feed, how did the foreign source get it? Further, I agree with what you wrote in <200504072017.CXR16597@ms8.netsolmail.com>: > Personally, I think we're safer if we only allow feeds to speak > about themselves. The moment we start down the road of granting > rights, we're heading towards quicksand. What I don’t know though, is whether this problem can be solved in entirety within the scope of the Atom format spec. It is probably safer and wiser for the spec to provide ways for republishers to make each others’ lives easier (cf Thomas’ atom:source suggestion), but not to dictate how they should do their jobs. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Thu Apr 7 17:28:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10222 for ; Thu, 7 Apr 2005 17:28:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LL5QL018114; Thu, 7 Apr 2005 14:21:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37LL5fm018113; Thu, 7 Apr 2005 14:21:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LL4Pk018099 for ; Thu, 7 Apr 2005 14:21:04 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta06-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050407212058.DDJE2577.mta13-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com>; Thu, 7 Apr 2005 22:20:58 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta06-winn.mailhost.ntl.com with ESMTP id <20050407212058.IUQM5678.aamta06-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com>; Thu, 7 Apr 2005 22:20:58 +0100 Date: Thu, 7 Apr 2005 22:20:55 +0100 From: David Powell X-Mailer: The Bat! (v3.0.9.13 Return) Professional X-Priority: 3 (Normal) Message-ID: <818618687.20050407222055@djpowell.net> To: Walter Underwood CC: bob@wyman.us, atom-syntax@imc.org Subject: Re: Spaces supports slash:comments. Result = Duplicates Galore! In-Reply-To: <1ADB790C2B8B9502FE024706@diva.verity.com> References: <200504071848.CXQ74688@ms8.netsolmail.com> <1ADB790C2B8B9502FE024706@diva.verity.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thursday, April 7, 2005, 8:10:18 PM, you wrote: > I still think we should address caching in Atom 1.0. This would > have been part of that. Scaling is an essential thing for syndication, > and caching is the best known way to scale. Me too. I'd like to see: atom:etag or atom:instanceId; or alternatively atom:modified. Having 1 publisher say whether an entry has changed seems more reliable than having thousands of different clients guess. -- Dave From owner-atom-syntax@mail.imc.org Thu Apr 7 17:33:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10690 for ; Thu, 7 Apr 2005 17:33:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LMWl7018296; Thu, 7 Apr 2005 14:22:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37LMWra018295; Thu, 7 Apr 2005 14:22:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LMV0P018286 for ; Thu, 7 Apr 2005 14:22:31 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJeSJ-0006us-4K; Thu, 07 Apr 2005 21:22:27 +0000 Message-ID: <4255A489.7020003@franklinmint.fm> Date: Thu, 07 Apr 2005 17:22:17 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Atom Syntax Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> In-Reply-To: <4255A185.4030608@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > Whether it is for accessibility, or for general usability, I want to > ensure that every entry has a textual, non-remote component to it. Yeah, but we can't really legislate that, can we? We are making editorial decisions for publishers via validity constraints. > You have made a number of noises that it is your intent to use last call > as your opportunity to challenge the working group to revisit this. > > Please don't. You are implying that would be somehow inappropriate or unsportsmanlike. It isn't. If there is consensus, such a challenge would be squashed rather quickly, don't you think? Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 7 18:01:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12734 for ; Thu, 7 Apr 2005 18:01:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LrW63021082; Thu, 7 Apr 2005 14:53:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37LrWa0021081; Thu, 7 Apr 2005 14:53:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LrVlh021075 for ; Thu, 7 Apr 2005 14:53:31 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j37LrVXi021079 for ; Thu, 7 Apr 2005 15:53:31 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEL00GZWJH6B9@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 07 Apr 2005 15:53:31 -0600 (MDT) Received: from [192.168.102.100] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEL002KRJH5UG@mail.sun.net> for atom-syntax@imc.org; Thu, 07 Apr 2005 15:53:30 -0600 (MDT) Date: Thu, 07 Apr 2005 14:54:01 -0700 From: Tim Bray Subject: Re: PaceCoConstraintsAreBad In-reply-to: <4255A489.7020003@franklinmint.fm> To: mint@franklinmint.fm Cc: Atom Syntax , Sam Ruby Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 7, 2005, at 2:22 PM, Robert Sayre wrote: >> Whether it is for accessibility, or for general usability, I want to >> ensure that every entry has a textual, non-remote component to it. > > Yeah, but we can't really legislate that, can we? We are making > editorial decisions for publishers via validity constraints. The line between "editorial decisions" and "technical constraints" is at best fuzzy. We are entirely within our rights as a WG to write a spec that requires the presence of certain elements. >> You have made a number of noises that it is your intent to use last >> call as your opportunity to challenge the working group to revisit >> this. >> Please don't. > > You are implying that would be somehow inappropriate or > unsportsmanlike. It isn't. If there is consensus, such a challenge > would be squashed rather quickly, don't you think? Just for the record, I strongly agree that Atom entries should be required to include (to use Sam's words) a textual non-remote component. -Tim From owner-atom-syntax@mail.imc.org Thu Apr 7 18:07:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13471 for ; Thu, 7 Apr 2005 18:07:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LvKCS021370; Thu, 7 Apr 2005 14:57:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37LvKG7021369; Thu, 7 Apr 2005 14:57:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LvKK8021363 for ; Thu, 7 Apr 2005 14:57:20 -0700 (PDT) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 2EF354F235; Thu, 7 Apr 2005 17:57:20 -0400 (EDT) Date: Thu, 7 Apr 2005 17:57:20 -0400 From: Dan Brickley To: Robert Sayre Cc: Sam Ruby , Atom Syntax Subject: Re: PaceCoConstraintsAreBad Message-ID: <20050407215719.GL24367@homer.w3.org> References: <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4255A489.7020003@franklinmint.fm> X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.6+20040907i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Robert Sayre [2005-04-07 17:22-0400] > > Sam Ruby wrote: > > > > >Whether it is for accessibility, or for general usability, I want to > >ensure that every entry has a textual, non-remote component to it. +1 > Yeah, but we can't really legislate that, can we? We are making > editorial decisions for publishers via validity constraints. This sounds roughly the same as requiring in HTML, eg. http://www.w3.org/TR/html4/struct/global.html#h-7.4.2 in that you can force documents to have some kind of title, but you can't legislate them into having sensible, accurate, etc titles. The schema can nudge people in the right direction though... Dan From owner-atom-syntax@mail.imc.org Thu Apr 7 18:11:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13964 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 18:11:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Lxn95021545; Thu, 7 Apr 2005 14:59:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37LxnWS021544; Thu, 7 Apr 2005 14:59:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37LxmEY021536 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 14:59:49 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJf2N-0007IB-O2; Thu, 07 Apr 2005 21:59:43 +0000 Message-ID: <4255AD4C.2090100@franklinmint.fm> Date: Thu, 07 Apr 2005 17:59:40 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Brickley <danbri@w3.org> CC: Sam Ruby <rubys@intertwingly.net>, Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad References: <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <20050407215719.GL24367@homer.w3.org> In-Reply-To: <20050407215719.GL24367@homer.w3.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Dan Brickley wrote: > * Robert Sayre <mint@franklinmint.fm> [2005-04-07 17:22-0400] > >>Sam Ruby wrote: >> >> >>>Whether it is for accessibility, or for general usability, I want to >>>ensure that every entry has a textual, non-remote component to it. > > > +1 > > >>Yeah, but we can't really legislate that, can we? We are making >>editorial decisions for publishers via validity constraints. > > > This sounds roughly the same as requiring <title> in HTML, eg. > http://www.w3.org/TR/html4/struct/global.html#h-7.4.2 in that you > can force documents to have some kind of title, but you can't > legislate them into having sensible, accurate, etc titles. The schema > can nudge people in the right direction though... Your example is roughly the same as requiring <atom:title>, which we do. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 7 18:18:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15023 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 18:18:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37M8EtM022154; Thu, 7 Apr 2005 15:08:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37M8EHX022153; Thu, 7 Apr 2005 15:08:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23]) by above.proper.com (8.12.11/8.12.9) with SMTP id j37M8DZu022136 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 15:08:14 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 3905 messnum 2895600 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 7 Apr 2005 22:08:08 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail07.svc.cra.dublin.eircom.net (qp 3905) with SMTP; 7 Apr 2005 22:08:08 -0000 Message-ID: <4255AF45.2050602@dehora.net> Date: Thu, 07 Apr 2005 23:08:05 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Powell <djpowell@djpowell.net> CC: atom-syntax@imc.org Subject: Re: Required elements for atom:source References: <67946152.20050407221329@djpowell.net> In-Reply-To: <67946152.20050407221329@djpowell.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit David Powell wrote: > > According to the RelaxNG: > > >> atomSource = >> element atom:source { >> atomCommonAttributes, >> (atomAuthor? >> & atomCategory* >> & atomContributor* >> & atomCopyright? >> & atomGenerator? >> & atomIcon? >> & atomId? >> & atomImage? >> & atomLink+ >> & atomSubtitle? >> & atomTitle >> & atomUpdated >> & extensionElement*) > > > ... atom:title and atom:updated are required for atom:source. > Is this a typo? > > I'd assume that no elements should be required for atom:source, on the > principle that anything that you can provide is better than nothing. My reading of the spec - not a typo. This could be like the situation I pointed out around simple and extension schema - if so the text ought to be amended to indicate the constraint. ** 4.2.14 The "atom:title" Element extend: [[[ The "atom:title" element is a Text construct that conveys a human-readable title for an entry or feed. ]]] with: "An atom:source MUST contain one atom:title element." ** 4.2.15 The "atom:updated" Element extend: [[[ The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant. Therefore, not all modifications necessarily result in a changed atom:updated value. ]]] with: "An atom:source MUST contain one atom:updated element." cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 7 18:18:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15054 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 18:18:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37MAH4F022295; Thu, 7 Apr 2005 15:10:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37MAHIS022294; Thu, 7 Apr 2005 15:10:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37MAGs6022282 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 15:10:16 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta06-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050407221010.CUN6951.mta09-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com> for <atom-syntax@imc.org>; Thu, 7 Apr 2005 23:10:10 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta06-winn.mailhost.ntl.com with ESMTP id <20050407221010.NPWI5678.aamta06-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com> for <atom-syntax@imc.org>; Thu, 7 Apr 2005 23:10:10 +0100 Date: Thu, 7 Apr 2005 23:10:07 +0100 From: David Powell <djpowell@djpowell.net> X-Mailer: The Bat! (v3.0.9.13 Return) Professional X-Priority: 3 (Normal) Message-ID: <1228968816.20050407231007@djpowell.net> To: atom-syntax@imc.org Subject: Comments links MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j37MAHs6022289 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit I'm currently experimenting with writing an XSLT stylesheet that transforms RSS 2.0 into the same RDF/XML model that my atom2rdf stylesheet[1] creates. Do we have an equivalent to RSS's <comments> [2] element? This is a pretty widely used feature of RSS — does it deserve a link/@rel value in Atom? [1] http://djpowell.net/atomrdf/0.1/ (Updated for draft-07 now btw.) [2] http://feedvalidator.org/docs/rss2.html#ltcommentsgtSubelementOfLtitemgt -- Dave From owner-atom-syntax@mail.imc.org Thu Apr 7 18:20:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15179 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 18:20:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37MCwq4022503; Thu, 7 Apr 2005 15:12:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37MCwoQ022502; Thu, 7 Apr 2005 15:12:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by above.proper.com (8.12.11/8.12.9) with SMTP id j37MCvbM022492 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 15:12:58 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 26614 messnum 7062836 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 7 Apr 2005 22:12:52 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail01.svc.cra.dublin.eircom.net (qp 26614) with SMTP; 7 Apr 2005 22:12:52 -0000 Message-ID: <4255B061.1000703@dehora.net> Date: Thu, 07 Apr 2005 23:12:49 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Broyer <t.broyer@cegetel.net> CC: Tim Bray <tim.bray@Sun.COM>, bob@wyman.us, atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... References: <200504071734.CXQ40556@ms8.netsolmail.com> <7374088810e564759f8d572481348f6f@sun.com> <425586E1.4040204@cegetel.net> <42558D67.3050700@dehora.net> <4255A131.3070102@cegetel.net> In-Reply-To: <4255A131.3070102@cegetel.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Thomas Broyer wrote: > Bill de hÓra wrote: > >> Thomas Broyer wrote: >> >>> Although this doesn't solve the DOS potential, I'd rather go for a >>> new atom:source child element indicating the source feed's Id or URI. >>> When PlanetBar and PlanetFoo republish a feed from Baz, they should >>> "move" the entry metadata into an atom:source element. >> >> >> >> One step further: how does that work for PlanetPlanet? > > > As I told in the phrase you stripped out? And will I be able to reverse engineer the order the atom:source annotations were added? I want to determine if this operation is robust and/or reversable beyond a single aggregation step. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 7 18:21:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15345 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 18:21:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37MFjEK022784; Thu, 7 Apr 2005 15:15:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37MFjAQ022783; Thu, 7 Apr 2005 15:15:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37MFiCP022773 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 15:15:44 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta06-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050407221538.HTQS928.mta08-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com>; Thu, 7 Apr 2005 23:15:38 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta06-winn.mailhost.ntl.com with ESMTP id <20050407221538.OCUF5678.aamta06-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com>; Thu, 7 Apr 2005 23:15:38 +0100 Date: Thu, 7 Apr 2005 23:15:36 +0100 From: David Powell <djpowell@djpowell.net> X-Mailer: The Bat! (v3.0.9.13 Return) Professional X-Priority: 3 (Normal) Message-ID: <7910428092.20050407231536@djpowell.net> To: =?windows-1252?Q?Bill_de_h=D3ra?= <bill@dehora.net> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: Obs on format-07 In-Reply-To: <425491E7.3020605@dehora.net> References: <425491E7.3020605@dehora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j37MFjCP022778 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit > - in 6.4; extension schema allow the use of the atom namespace as child > elements of the extension. I do not recall this being discussed, but > personally am +1 to it. Yeah, I'm ok with it too. I'm not sure why anyone would want to do it, but the spirit of Structured Extension elements was that (almost) anything goes. -- Dave From owner-atom-syntax@mail.imc.org Thu Apr 7 18:30:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15979 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 18:30:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37MOMRk023667; Thu, 7 Apr 2005 15:24:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37MOLEP023663; Thu, 7 Apr 2005 15:24:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37MOJ4g023572 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 15:24:20 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.69.81]) by smtp.cegetel.net (Postfix) with ESMTP id A6C85381F0; Fri, 8 Apr 2005 00:24:13 +0200 (CEST) Message-ID: <4255B312.5040804@cegetel.net> Date: Fri, 08 Apr 2005 00:24:18 +0200 From: Thomas Broyer <t.broyer@cegetel.net> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> Cc: Tim Bray <tim.bray@Sun.COM>, bob@wyman.us, atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... References: <200504071734.CXQ40556@ms8.netsolmail.com> <7374088810e564759f8d572481348f6f@sun.com> <425586E1.4040204@cegetel.net> <42558D67.3050700@dehora.net> <4255A131.3070102@cegetel.net> <4255B061.1000703@dehora.net> In-Reply-To: <4255B061.1000703@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > Thomas Broyer wrote: > >> Bill de hÓra wrote: >> >>> Thomas Broyer wrote: >>> >>>> Although this doesn't solve the DOS potential, I'd rather go for a >>>> new atom:source child element indicating the source feed's Id or >>>> URI. When PlanetBar and PlanetFoo republish a feed from Baz, they >>>> should "move" the entry metadata into an atom:source element. >>> >>> >>> >>> >>> One step further: how does that work for PlanetPlanet? >> >> >> >> As I told in the phrase you stripped out? > > > And will I be able to reverse engineer the order the atom:source > annotations were added? I want to determine if this operation is robust > and/or reversable beyond a single aggregation step. Well, depends what you mean by "reverse engineer" and "reversable", I'm not sure to understand... IMHO, only the first re-publisher changes the entry to move the metadata from atom:entry to atom:source (and adds the atom:feedId or whatever its name). If an entry already has an atom:source child, you just republish it as-is. If you move the atom:source children back into the atom:entry element (and strip the atom:feedId), you should (and it is a should since the use of atom:source is currently a should in the spec) have the same entry as in the "primary" feed. Additionally, the content of the atom:source/atom:feedId tells you the URI of that "primary" feed at the time the entry was republished. Sorry if I didn't answer you question as I might have misinterpreted it... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Apr 7 18:47:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17383 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 18:47:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37MdTIZ024801; Thu, 7 Apr 2005 15:39:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37MdTrY024800; Thu, 7 Apr 2005 15:39:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37MdTfb024794 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 15:39:29 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j37MdPeB020706; Thu, 7 Apr 2005 18:39:25 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CXR73119 (AUTH bob@wyman.us); Thu, 7 Apr 2005 18:39:24 -0400 (EDT) Message-Id: <200504072239.CXR73119@ms8.netsolmail.com> Reply-To: <bob@wyman.us> From: "Bob Wyman" <bob@wyman.us> To: "'Thomas Broyer'" <t.broyer@cegetel.net>, "=?iso-8859-1?Q?'Bill_de_h=D3ra'?=" <bill@dehora.net> Cc: "'Tim Bray'" <tim.bray@Sun.COM>, <bob@wyman.us>, <atom-syntax@imc.org> Subject: RE: One reason we have duplicates entries is that we have duplicate feeds... Date: Thu, 7 Apr 2005 18:39:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <4255B312.5040804@cegetel.net> Thread-Index: AcU7wI8RfBSJJT66Szi1yyBZk2P5UgAAVkrw Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j37MdTfb024795 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Thomas Broyer wrote in response to Bill de hÓra: > If an entry already has an atom:source child, you just republish > it as-is. [And, if it doesn't have an atom:source, you insert one.] This is what was agreed, I believe, when the issue was discussed on the list. To do anything more would be addressing the "path" or "provenance" issue (i.e. answering "How did this get here?"). The source element is only intended to provide that data which would have been available to a reader if the entry had been found in its source feed. Any other data that might be interesting (and there is a great deal of it) is the problem of some other element to handle. bob wyman From owner-atom-syntax@mail.imc.org Thu Apr 7 18:47:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17431 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 18:47:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37MhHAU025096; Thu, 7 Apr 2005 15:43:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37MhHgD025095; Thu, 7 Apr 2005 15:43:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37MhHGd025089 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 15:43:17 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j37MhEmp007056; Thu, 7 Apr 2005 18:43:15 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CXR74351 (AUTH bob@wyman.us); Thu, 7 Apr 2005 18:43:13 -0400 (EDT) Message-Id: <200504072243.CXR74351@ms8.netsolmail.com> Reply-To: <bob@wyman.us> From: "Bob Wyman" <bob@wyman.us> To: "'David Powell'" <djpowell@djpowell.net>, <atom-syntax@imc.org> Subject: RE: Required elements for atom:source Date: Thu, 7 Apr 2005 18:43:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <67946152.20050407221329@djpowell.net> Thread-Index: AcU7ueqMugF1pQaWSP2LCwmdVWxdowACPV+g Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Personally, I think the atom:source should have a required link which points to the feed that is claimed to be the source... bob wyman From owner-atom-syntax@mail.imc.org Thu Apr 7 18:52:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17736 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 18:52:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Mj8qS025216; Thu, 7 Apr 2005 15:45:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37Mj8Nj025215; Thu, 7 Apr 2005 15:45:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Mj8Lk025203 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 15:45:08 -0700 (PDT) (envelope-from mint@franklinmint.fm) Date: Thu, 7 Apr 2005 15:45:08 -0700 (PDT) Message-Id: <200504072245.j37Mj8Lk025203@above.proper.com> Received: from localhost ([127.0.0.1]) by web02.designerslab.net with smtp (Exim 4.43) id 1DJfhl-0007jX-Lr for atom-syntax@imc.org; Thu, 07 Apr 2005 22:45:04 +0000 From: Robert Sayre <mint@franklinmint.fm> To: Atom-Syntax <atom-syntax@imc.org> In-reply-to: <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> Subject: This message contains no body. Still works. (was: PaceCoConstraintsAreBad) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> From owner-atom-syntax@mail.imc.org Thu Apr 7 19:10:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19264 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 19:10:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37N2tMI027744; Thu, 7 Apr 2005 16:02:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37N2tU9027743; Thu, 7 Apr 2005 16:02:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37N2sOi027723 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 16:02:55 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050407230248.IZIG6951.mta09-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com> for <atom-syntax@imc.org>; Fri, 8 Apr 2005 00:02:48 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050407230248.HWFX1187.aamta01-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com> for <atom-syntax@imc.org>; Fri, 8 Apr 2005 00:02:48 +0100 Date: Fri, 8 Apr 2005 00:02:45 +0100 From: David Powell <djpowell@djpowell.net> X-Mailer: The Bat! (v3.0.9.13 Return) Professional X-Priority: 3 (Normal) Message-ID: <496491534.20050408000245@djpowell.net> To: Atom Syntax <atom-syntax@imc.org> Subject: atom:source interactions with xml:base/xml:lang MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit The inheritance of @xml:lang and @xml:base creates a lot of complexities for an implementation. When they are used in combination with atom:source, things get particularly bad. Should we add some notes to the spec to remind people how to correctly handle base and lang when atom:source-ifying entries? A couple of the complexities are: 1) An @xml:base attribute declared on an entry might be relative to the original feed's URI, or to @xml:base attributes on parent elements. These need to be resolved before they can be copied across into a second feed. 2) The source feed will have atom:entry as a child of atom:feed, but the second feed will have atom:source as a child of atom:entry. This switch in the hierarchy means that if the source feed contains an @xml:lang tag on its entry, but not on its feed, you need to undeclare @xml:lang on atom:source. Likewise, any @xml:base on atom:entry need to be resolved because it can no longer be relative to the base of the atom:feed element. Eg: <atom:feed> <atom:title>Source feed</atom:title> ... <atom:entry xml:lang="de"> <atom:title>Guten Tag</atom:title> ... </atom:entry> <atom:feed> needs to be embedded as: <atom:feed> <atom:title>Second feed</atom:title> ... <atom:entry xml:lang="de"> <atom:source xml:lang=""> <atom:title>Source feed</atom:title> ... </atom:source> <atom:title>Guten Tag</atom:title> ... </atom:entry> <atom:feed> -- Dave From owner-atom-syntax@mail.imc.org Thu Apr 7 19:20:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19665 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 19:20:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37NEXLY028785; Thu, 7 Apr 2005 16:14:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37NEW2K028784; Thu, 7 Apr 2005 16:14:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37NEVWE028772 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 16:14:32 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j37NEP723556; Fri, 8 Apr 2005 08:14:25 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id a416864a_a7ba_11d9_9dae_0030482533a1_25673; Fri, 08 Apr 2005 08:13:24 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO001914; 8 Apr 05 08:15:22 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 8 Apr 05 08:15:06 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.250.1) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG001912; 8 Apr 05 08:14:59 +0900 Message-Id: <6.0.0.20.2.20050408081319.05f91dd0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 08 Apr 2005 08:13:40 +0900 To: David Powell <djpowell@djpowell.net>, Atom Syntax <atom-syntax@imc.org> From: Martin Duerst <duerst@it.aoyama.ac.jp> Subject: Re: atom:source interactions with xml:base/xml:lang In-Reply-To: <496491534.20050408000245@djpowell.net> References: <496491534.20050408000245@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit +1 to adding these kinds of clarifications and examples to the spec! Regards, Martin. At 08:02 05/04/08, David Powell wrote: > > >The inheritance of @xml:lang and @xml:base creates a lot of >complexities for an implementation. When they are used in combination >with atom:source, things get particularly bad. > >Should we add some notes to the spec to remind people how to correctly >handle base and lang when atom:source-ifying entries? > > >A couple of the complexities are: > >1) An @xml:base attribute declared on an entry might be relative to >the original feed's URI, or to @xml:base attributes on parent >elements. These need to be resolved before they can be copied across >into a second feed. > >2) The source feed will have atom:entry as a child of atom:feed, but >the second feed will have atom:source as a child of atom:entry. This >switch in the hierarchy means that if the source feed contains an >@xml:lang tag on its entry, but not on its feed, you need to undeclare >@xml:lang on atom:source. Likewise, any @xml:base on atom:entry need >to be resolved because it can no longer be relative to the base of the >atom:feed element. > >Eg: > > <atom:feed> > <atom:title>Source feed</atom:title> > ... > <atom:entry xml:lang="de"> > <atom:title>Guten Tag</atom:title> > ... > </atom:entry> > <atom:feed> > > >needs to be embedded as: > > <atom:feed> > <atom:title>Second feed</atom:title> > ... > <atom:entry xml:lang="de"> > <atom:source xml:lang=""> > <atom:title>Source feed</atom:title> > ... > </atom:source> > <atom:title>Guten Tag</atom:title> > ... > </atom:entry> > <atom:feed> > >-- >Dave From owner-atom-syntax@mail.imc.org Thu Apr 7 19:53:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21067 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 19:53:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37Njr3R031119; Thu, 7 Apr 2005 16:45:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37Njr77031118; Thu, 7 Apr 2005 16:45:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18]) by above.proper.com (8.12.11/8.12.9) with SMTP id j37NjqXu031107 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 16:45:52 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 22484 messnum 5251471 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 7 Apr 2005 23:45:46 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail02.svc.cra.dublin.eircom.net (qp 22484) with SMTP; 7 Apr 2005 23:45:46 -0000 Message-ID: <4255C627.7050001@dehora.net> Date: Fri, 08 Apr 2005 00:45:43 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre <mint@franklinmint.fm> CC: Atom-Syntax <atom-syntax@imc.org> Subject: bad example; try, I won't be working on atom this weekend (eom) [was Re: This message contains no body. Still works.] References: <200504072245.j37Mj8Lk025203@above.proper.com> In-Reply-To: <200504072245.j37Mj8Lk025203@above.proper.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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit From owner-atom-syntax@mail.imc.org Thu Apr 7 19:54:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21207 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 19:54:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37NmaIg031394; Thu, 7 Apr 2005 16:48:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37NmaHR031393; Thu, 7 Apr 2005 16:48:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j37NmZc4031378 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 16:48:35 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 88768 messnum 5770850 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 7 Apr 2005 23:48:29 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail12.svc.cra.dublin.eircom.net (qp 88768) with SMTP; 7 Apr 2005 23:48:29 -0000 Message-ID: <4255C6CA.509@dehora.net> Date: Fri, 08 Apr 2005 00:48:26 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Thomas Broyer'" <t.broyer@cegetel.net>, "'Tim Bray'" <tim.bray@Sun.COM>, atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... References: <200504072239.CXR73119@ms8.netsolmail.com> In-Reply-To: <200504072239.CXR73119@ms8.netsolmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Bob Wyman wrote: > Thomas Broyer wrote in response to Bill de hÓra: > >>If an entry already has an atom:source child, you just republish >>it as-is. [And, if it doesn't have an atom:source, you insert one.] > > This is what was agreed, I believe, when the issue was discussed on > the list. To do anything more would be addressing the "path" or "provenance" > issue (i.e. answering "How did this get here?"). > The source element is only intended to provide that data which would > have been available to a reader if the entry had been found in its source > feed. Any other data that might be interesting (and there is a great deal of > it) is the problem of some other element to handle. Ok. The format spec ought to document what is expected to happen downstream in the event of repeated aggregations. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 7 19:58:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21387 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 19:58:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37NsCU4031839; Thu, 7 Apr 2005 16:54:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j37NsCJZ031838; Thu, 7 Apr 2005 16:54:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j37NsBwb031823 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 16:54:12 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050407235405.UZD2577.mta13-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>; Fri, 8 Apr 2005 00:54:05 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050407235405.CEDM1352.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com>; Fri, 8 Apr 2005 00:54:05 +0100 Date: Fri, 8 Apr 2005 00:50:58 +0100 From: David Powell <djpowell@djpowell.net> X-Mailer: The Bat! (v3.0.9.13 Return) Professional X-Priority: 3 (Normal) Message-ID: <1913468020.20050408005058@djpowell.net> To: Martin Duerst <duerst@it.aoyama.ac.jp> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: atom:source interactions with xml:base/xml:lang In-Reply-To: <6.0.0.20.2.20050408081319.05f91dd0@itmail.it.aoyama.ac.jp> References: <496491534.20050408000245@djpowell.net> <6.0.0.20.2.20050408081319.05f91dd0@itmail.it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Friday, April 8, 2005, 12:13:40 AM, Martin Duerst wrote: > +1 to adding these kinds of clarifications and examples to the spec! The simplest thing would probably be to RECOMMEND that processors resolve the base and lang values for the atom:entry and atom:feed elements of source feed, and explicitly set these attributes on the atom:entry and atom:source elements of the embedded entry. -- Dave From owner-atom-syntax@mail.imc.org Thu Apr 7 20:06:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21707 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 20:06:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3800TkU032380; Thu, 7 Apr 2005 17:00:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3800Tfr032379; Thu, 7 Apr 2005 17:00:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3800Mst032347 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 17:00:26 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 8 Apr 2005 06:00:13 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 08 Apr 2005 10:00:13 +1000 Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE7C06AD.50BFC%eric.scheid@ironclad.net.au> In-Reply-To: <200504072017.CXR16597@ms8.netsolmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 8/4/05 6:17 AM, "Bob Wyman" <bob@wyman.us> wrote: > A side benefit of having "primary feeds" would be that people would > be more likely to do things like include full "category" data in the entries > they publish rather than publishing entries into specialized feeds as the > way to indicate "category." publishers don't do that to indicate category, they do that to minimize bandwidth (both bits on the wire, and bits on the brain). e. From owner-atom-syntax@mail.imc.org Thu Apr 7 20:06:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21752 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 20:06:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3801sYR032595; Thu, 7 Apr 2005 17:01:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3801skF032594; Thu, 7 Apr 2005 17:01:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3801rdO032588 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 17:01:53 -0700 (PDT) (envelope-from mint@franklinmint.fm) Date: Thu, 7 Apr 2005 17:01:53 -0700 (PDT) Message-Id: <200504080001.j3801rdO032588@above.proper.com> Received: from localhost ([127.0.0.1]) by web02.designerslab.net with smtp (Exim 4.43) id 1DJgtJ-0008Sw-9g; Fri, 08 Apr 2005 00:01:48 +0000 From: Robert Sayre <mint@franklinmint.fm> To: Bill <bill@dehora.net> Cc: Atom-Syntax <atom-syntax@imc.org> In-reply-to: <4255C627.7050001@dehora.net> Subject: I don't get it, perhaps you could include an expanded explanation in a textual message, now that our machine protocol has broken down. X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> From owner-atom-syntax@mail.imc.org Thu Apr 7 20:10:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21929 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 20:10:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3803SHa032761; Thu, 7 Apr 2005 17:03:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3803Svt032760; Thu, 7 Apr 2005 17:03:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3803MQK032748 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 17:03:23 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 8 Apr 2005 06:03:17 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 08 Apr 2005 10:03:18 +1000 Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE7C0766.50C12%eric.scheid@ironclad.net.au> In-Reply-To: <200504072017.CXR16597@ms8.netsolmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 8/4/05 6:17 AM, "Bob Wyman" <bob@wyman.us> wrote: > The proposal I made relies on a feed making statements only about > itself. In my proposal, a feed can only say: "I contain copies of these > other feeds. I am a secondary feed." How does this prevent DOS attacks? If I could insert entries with faked <atom:id>, could I not also insert entries with faked <atom:source>, or any other identification meta-data? If my entry has a more recent atom:modified, then it would replace any earlier entries you've seen with [whatever] metadata, right? e. From owner-atom-syntax@mail.imc.org Thu Apr 7 20:17:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22367 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 20:17:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j380Cp7Y033569; Thu, 7 Apr 2005 17:12:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j380CpR3033568; Thu, 7 Apr 2005 17:12:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j380Cl2X033549 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 17:12:49 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 8 Apr 2005 06:11:36 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 08 Apr 2005 10:07:18 +1000 Subject: Re: Spaces supports slash:comments. Result = Duplicates Galore! From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE7C0856.50C12%eric.scheid@ironclad.net.au> In-Reply-To: <20050407204913.GA26197@klangraum> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j380Co2X033563 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On 8/4/05 6:49 AM, "A. Pagaltzis" <pagaltzis@gmx.de> wrote: > I don¹t believe we can forsee > all of these, so let¹s not try to. The Atom format should specify > hooks (such as the atom:source subelement Thomas suggested, > possibly?) which would allow trust models or other coping > mechanisms to be implemented, but leave their precise nature to > the discreetion of implementors after bringing the potential > problems to attention. +1 I don't think we can boil all the spammers out of the syndication ocean in the 1.0 spec. e. From owner-atom-syntax@mail.imc.org Thu Apr 7 22:19:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01219 for <atompub-archive@lists.ietf.org>; Thu, 7 Apr 2005 22:19:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j382CfKt044861; Thu, 7 Apr 2005 19:12:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j382Cfn5044860; Thu, 7 Apr 2005 19:12:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j382Cd2r044852 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 19:12:40 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j382Ccmm005746; Thu, 7 Apr 2005 22:12:39 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CXS25747; Thu, 7 Apr 2005 22:12:37 -0400 (EDT) Message-Id: <200504080212.CXS25747@ms8.netsolmail.com> Reply-To: <bob@wyman.us> From: "Bob Wyman" <bob@wyman.us> To: "'Eric Scheid'" <eric.scheid@ironclad.net.au>, "'Atom Syntax'" <atom-syntax@imc.org> Subject: RE: One reason we have duplicates entries is that we haveduplicate feeds... Date: Thu, 7 Apr 2005 22:12:35 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <BE7C0766.50C12%eric.scheid@ironclad.net.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU70D/T7f7LSD6dTNuqgqmG6ZySOAACGc9A Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Eric Scheid wrote: >>On 8/4/05 6:17 AM, "Bob Wyman" <bob@wyman.us> wrote: >> The proposal I made relies on a feed making statements only about >> itself. In my proposal, a feed can only say: "I contain copies of >> these other feeds. I am a secondary feed." > How does this prevent DOS attacks? If I could insert entries with faked > <atom:id>, could I not also insert entries with faked <atom:source>, > or any other identification meta-data? Sure, you could create entries that had faked atom:id's but well designed readers would only considered your entries to be duplicates if they appeared in feeds that the "feed under attack" had explicitly declared itself to be secondary to. Entries with duplicate ids that appeared anywhere else in the blogosphere would not be considered duplicates. This severely constrains the opportunity for DOS attacks, substitutions, etc. Readers must assume that the world is filled with entries that all use the same atom:ids. The task for the reader is to figure out, among all the entries that use the same atom:id, which are actually duplicates or legitimate replacements of each other. The essential thing to understand here is that while creators of atom:ids should do what the spec says and create atom:ids that are globally unique, readers of atom:ids simply cannot assume that atom:ids are, in fact, globally unique. (No repetition of MUST's or SHOULD's in the spec will change this truth.) Without any additional information, a reader can only just barely assume that an atom:id is unique within a single feed and even then, only in those entries of the feed that do not contain atom:source elements indicating that the entries have been copied from a foreign feed. If the community accepts this idea of "primary" and "secondary" or "authoritative" and "non-authoritative" feeds and entries, it should be obvious that an entry which is contained in a feed, yet has an atom:source indicating a foreign feed, should *always* be treated as non-authoritative (unless, of course, the feed was published by someone you trust or the entry has a digital signature that can be associated with the entry's source feed -- these mechanisms aren't defined yet). Please remember that what I'm talking about here concerns the processing model for Atom feeds or the semantics of the system composed of real-world atom feeds and real-world atom processors. To date, most of our discussions have been simply about the syntax (atom-syntax...) for feeds and entries. It is great that the atom-syntax requires uniqueness in ids. You just can't expect processors to be terribly influenced by the fact that the uniqueness requirement exists. bob wyman From owner-atom-syntax@mail.imc.org Fri Apr 8 01:41:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15149 for <atompub-archive@lists.ietf.org>; Fri, 8 Apr 2005 01:41:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j385XQDo084967; Thu, 7 Apr 2005 22:33:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j385XQx6084966; Thu, 7 Apr 2005 22:33:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j385XPeg084947 for <atom-syntax@imc.org>; Thu, 7 Apr 2005 22:33:25 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12ld2tn.cable.mindspring.com ([69.86.139.183] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DJm7P-0004vT-AS; Fri, 08 Apr 2005 05:33:23 +0000 Message-ID: <425617A0.4010008@franklinmint.fm> Date: Fri, 08 Apr 2005 01:33:20 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray <Tim.Bray@Sun.COM> CC: Atom Syntax <atom-syntax@imc.org>, Sam Ruby <rubys@intertwingly.net> Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> In-Reply-To: <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Tim Bray wrote: >> You are implying that would be somehow inappropriate or >> unsportsmanlike. It isn't. If there is consensus, such a challenge >> would be squashed rather quickly, don't you think? > > > Just for the record, I strongly agree that Atom entries should be > required to include (to use Sam's words) a textual non-remote > component. In the words of your co-chair, this isn't a negotiating game. Accessibility is a non-starter absent expert opinion or substantially similar formats. Frankly, the notion that remote content constitutes an accessibility concern is absurd. Might as well write off the whole Web. What harm is our use of RFC2119 imperatives trying to prevent? Applying Dan Gillmor's definition of stupid[0] is a textbook case of trying "to impose a particular method on implementors". Robert Sayre [0] http://www.imc.org/atom-protocol/mail-archive/msg00555.html From owner-atom-syntax@mail.imc.org Fri Apr 8 05:06:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20490 for <atompub-archive@lists.ietf.org>; Fri, 8 Apr 2005 05:06:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j388wGHS068245; Fri, 8 Apr 2005 01:58:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j388wGBW068244; Fri, 8 Apr 2005 01:58:16 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j388wEhk068195 for <atom-syntax@imc.org>; Fri, 8 Apr 2005 01:58:14 -0700 (PDT) (envelope-from laurent.lemeur@afp.com) Received: by smtp1.afp.com (Sendmail, from userid 1007) id 09B634674C; Fri, 8 Apr 2005 10:57:05 +0200 (CEST) Received: from alox.afp.com (unknown [158.50.165.141])by smtp1.afp.com (Sendmail) with ESMTP id 6F64F4640Efor <atom-syntax@imc.org>; Fri, 8 Apr 2005 10:57:04 +0200 (CEST) Received: from stdc05bis ([158.50.180.254])by alox.afp.com (8.12.9/8.12.9) with ESMTP id j388vsWu020015for <atom-syntax@imc.org>; Fri, 8 Apr 2005 10:57:59 +0200 (METDST) Message-Id: <200504080857.j388vsWu020015@alox.afp.com> From: "Laurent Le Meur" <laurent.lemeur@afp.com> To: "'Atom Syntax'" <atom-syntax@imc.org> Subject: Announcing the Second International News Standards Summit Date: Fri, 8 Apr 2005 10:57:56 +0200 MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcU7/LLzljPi2NAISPCviAdu1F4n4QAG4Gbw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <425617A0.4010008@franklinmint.fm> X-MailScanner: Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j388wGhk068237 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit XML for News - Everything You Always Wanted to Know but Were Afraid to Ask. Get the answers at the News Standards Summit on May 24 in Amsterdam: http://www.newssummit.org/2005/ Note: Includes a session on Atom and RSS developments. Laurent Le Meur AFP - Head of Medialab IPTC News Architecture WP chair ================= Press release ================= IPTC: Announcing the Second International News Standards Summit Leaders in News Standards Development and Implementations to Meet in Amsterdam Windsor, England - 6 April 2005 - The International Press Telecommunications Council IPTC, today announced that they are proud to co-sponsor the second international News Standards Summit to be held on May 24, 2005 in conjunction with the IDEAlliance XTech 2005 Conference at the Amsterdam RAI Centre, the Netherlands. The Summit is a collaborative effort of organizations committed to open standards development. Sponsors include IPTC (http://www.iptc.org), G- SAM (http://www.g-sam.org), IDEAlliance (http://www.idealliance.org), and Ifra (http://www.ifra.com). The News Standards Summit will bring together major players--experts on news metadata standards as well as commercial news providers, users, and aggregators. As interest builds for standardizing news dissemination, concern also grows that specifications are being developed in isolation. How can the standards fit together? Where/how will standards converge? How can the industry collaborate to identify gaps and overlaps and ensure their systems will be able to interoperate now and in the future? Together, participants will analyze the current state and future expectations for news and publishing XML efforts from both the content and processing model perspectives. The goal of the summit is to increase understanding about the state of news standards, to highlight standards-based implementation and to drive practical, productive convergence. The program will feature presentations from the key news standards efforts balanced by an implementation status report from a panel of international users. The day will conclude with an open session where productive ideas for moving forward will be proposed. Networking with others in the News Industry is a key component of the Summit. All program and registration information is available at http://www.newssummit.org/ Those who attend the summit will be given a discount on registration for the XTech 2005 Conference. (http://www.xtech-conference.org/2005/registration.asp ) About the IPTC The IPTC, International Press Telecommunications Council, is a not-for-profit consortium of the world's major news agencies, news publishers and news industry system vendors based in Windsor, England. It develops and maintains technical standards that are used by virtually every major news organisation in the world. These standards cover news exchange formats like IPTC7901, IIM, NITF, NewsML and SportsML, metadata container schemas like the "IPTC Core" as well as metadata taxonomies like the Subject NewsCodes. Find more about the IPTC at http://www.iptc.org About G-SAM G-SAM is a not for profit professional Trade Association, which exists to promote the development and adoption of technologies to manage, protect and create value from digital assets. The group promotes integrated products and processes that support interoperability and open standards that will drive adoption and user acceptance of digital asset management (DAM) and related technologies with over 200 corporate members worldwide. Principal Founding Members of G-SAM are Avid Technology (NYSE: AVID), IBM (NYSE: IBM), Ascent Media (NYSE:L), Artesia Technologies, Sony (NYSE: SNE) and WAM!NET, a division of SAVVIS Communications (SVVS), Harris Corporation (NYSE:HRS), and Quark. For more information, please visit http://www.gsam.org. About IDEAlliance IDEAlliance (International Digital Enterprise Alliance) is a not-for-profit membership organization advancing user-driven, cross-industry solutions for all publishing and content-related processes by developing standards, fostering business alliances, and identifying best practices. IDEAlliance has been a leader in information technology - developing Document Markup Metalanguage (GENCODE), sponsoring the development of Standard Generalized Markup Language (SGML), and fostering eXtensible Markup Language (XML). IDEAlliance builds on these languages to create specifications including Publishing Requirements for Industry Standard Metadata (PRISM), Digital Image Submission Criteria (DISC) and Information and Content Exchange (ICE) that enhance efficiency and speed information in all aspects of publishing and content-related processes. Learn more about IDEAlliance at www.idealliance.org. About IFRA Ifra, the world's leading association for media publishing, is a service organisation dedicated to the publishing industry worldwide. More than 2000 publishing companies and suppliers to the publishing industry are currently Ifra members. Ifra is their forum to exchange experiences and to learn from one another. Ifra's name originates from "INCA-FIEJ Research Association", whereby "INCA" stands for "International Newspaper Colour Association" and "FIEJ" stands for "Fédération Internationale des Editeurs de Journaux". Today the name "Ifra" stands by itself. About XTech XTech is a key forum for the web, XML, and open standards worlds. Formerly known as the XML Europe Conference, XTech has widened its scope to incorporate neighbouring technologies from the web and business. As well as XML, XTech 2005 will cover web development, browsers, open data, the semantic web and more. - 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 Fri Apr 8 09:34:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18821 for <atompub-archive@lists.ietf.org>; Fri, 8 Apr 2005 09:34:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38DEiZ7060117; Fri, 8 Apr 2005 06:14:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38DEi7f060116; Fri, 8 Apr 2005 06:14:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38DEgfG060097 for <atom-syntax@imc.org>; Fri, 8 Apr 2005 06:14:43 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-101.dti.cegetel.net [217.19.192.101]) by smtp.cegetel.net (Postfix) with SMTP id 435C5672B4; Fri, 8 Apr 2005 15:14:34 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Fri, 8 Apr 2005 15:14:35 +0200 (CEST) Message-ID: <3621.82.127.77.43.1112966075.squirrel@ssl-webmail.sitadelle.com> Date: Fri, 8 Apr 2005 15:14:35 +0200 (CEST) Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... From: "Thomas Broyer" <t.broyer@cegetel.net> To: <t.broyer@cegetel.net> In-Reply-To: <425586E1.4040204@cegetel.net> References: <200504071734.CXQ40556@ms8.netsolmail.com> <7374088810e564759f8d572481348f6f@sun.com> <425586E1.4040204@cegetel.net> X-Priority: 3 Importance: Normal Cc: <tim.bray@Sun.COM>, <bob@wyman.us>, <atom-syntax@imc.org> X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Doh! Seems I was very tired yesterday night... Thomas Broyer wrote: > [...] atom:source child element indicating the source feed's Id or URI [...] This already exists with atom:id and atom:link rel="self". However, I'd go for a MUST or at least a SHOULD on the atom:source presence in republished entries, along with a MUST in the metadata from the source feed that would be copied into the atom:source element: if you use atom:source, then you MUST copy all the Atom-defined feed metadata into the atom:source element, and you SHOULD (or MAY ?) copy extension metadata as well. > [...] "move" the entry metadata into an atom:source element. [ ...] ...move the *feed* metadata into an atom:source element... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Fri Apr 8 11:17:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02123 for <atompub-archive@lists.ietf.org>; Fri, 8 Apr 2005 11:17:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38F8QIr069240; Fri, 8 Apr 2005 08:08:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38F8QeQ069239; Fri, 8 Apr 2005 08:08:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j38F8OD0069231 for <atom-syntax@imc.org>; Fri, 8 Apr 2005 08:08:24 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 68107 messnum 5279491 invoked from network[213.94.211.166/mail2.newbay.com]); 8 Apr 2005 12:23:43 -0000 Received: from mail2.newbay.com (HELO ?127.0.0.1?) (213.94.211.166) by mail04.svc.cra.dublin.eircom.net (qp 68107) with SMTP; 8 Apr 2005 12:23:43 -0000 Message-ID: <425677CD.2020305@dehora.net> Date: Fri, 08 Apr 2005 13:23:41 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre <mint@franklinmint.fm> CC: Atom-Syntax <atom-syntax@imc.org> Subject: Re: I don't get it, perhaps you could include an expanded explanation in a textual message, now that our machine protocol has broken down. 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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit :) Only that it's common enough (in my part of the world anyway) to send short messages in subject lines that end with 'eom'. The point is that people do communicate solely through subject lines in email. I think that probably lends weight to your position. cheers Bill From owner-atom-syntax@mail.imc.org Fri Apr 8 11:21:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02241 for <atompub-archive@lists.ietf.org>; Fri, 8 Apr 2005 11:21:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38FEHHH069608; Fri, 8 Apr 2005 08:14:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38FEH7L069607; Fri, 8 Apr 2005 08:14:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38FEGNU069600 for <atom-syntax@imc.org>; Fri, 8 Apr 2005 08:14:16 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 13268 invoked by uid 17064); 8 Apr 2005 15:14:14 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.139.251]) (envelope-sender <henry.story@bblfish.net>) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for <atom-syntax@imc.org>; 8 Apr 2005 15:14:14 -0000 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <425677CD.2020305@dehora.net> References: <425677CD.2020305@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <aaf1ccbd7aa9358810c6c4946613f030@bblfish.net> From: Henry Story <henry.story@bblfish.net> Subject: Re: I don't get it, perhaps you could include an expanded explanation in a textual message, now that our machine protocol has broken down. Date: Fri, 8 Apr 2005 17:14:12 +0200 To: Atom Syntax <atom-syntax@imc.org> X-Mailer: Apple Mail (2.619.2) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j38FEGNU069602 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit My mother does this all the time. :-) On 8 Apr 2005, at 14:23, Bill de hÓra wrote: > > :) > > Only that it's common enough (in my part of the world anyway) to send > short messages in subject lines that end with 'eom'. The point is that > people do communicate solely through subject lines in email. I think > that probably lends weight to your position. > > cheers > Bill > From owner-atom-syntax@mail.imc.org Fri Apr 8 19:07:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20126 for <atompub-archive@lists.ietf.org>; Fri, 8 Apr 2005 19:07:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38MqrVD004243; Fri, 8 Apr 2005 15:52:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38MqrHK004242; Fri, 8 Apr 2005 15:52:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38MqrrW004233 for <atom-syntax@imc.org>; Fri, 8 Apr 2005 15:52:53 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id D70D0FC for <atom-syntax@imc.org>; Fri, 8 Apr 2005 15:52:47 -0700 (PDT) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j38Mqlng020101 for <atom-syntax@imc.org>; Fri, 8 Apr 2005 15:52:47 -0700 (PDT) Date: Fri, 08 Apr 2005 15:56:48 -0700 From: Walter Underwood <wunder@verity.com> To: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad Message-ID: <52471BC19BE5F24CD67F7562@diva.verity.com> In-Reply-To: <425617A0.4010008@franklinmint.fm> References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit --On Friday, April 08, 2005 01:33:20 AM -0400 Robert Sayre <mint@franklinmint.fm> wrote: > > Accessibility is a non-starter absent expert opinion or substantially > similar formats. Frankly, the notion that remote content constitutes an > accessibility concern is absurd. Might as well write off the whole Web. No, non-accessible designs are non-starters. I am mystified when I see non-accessible web sites and technologies deployed. If a building was build with round doorknobs and steps, the architect would not get paid until it was fixed and made accessible. Why is discrimination OK on the web? Accessibility is required by law, and not just in the US. Plus, it is an "essential aspect" of the web. "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." -- Tim Berners-Lee <http://www.w3.org/WAI/> Is that expert enough for you? wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Fri Apr 8 19:13:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20450 for <atompub-archive@lists.ietf.org>; Fri, 8 Apr 2005 19:13:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38MxxWm004672; Fri, 8 Apr 2005 15:59:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j38MxxMe004671; Fri, 8 Apr 2005 15:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j38MxvEQ004663 for <atom-syntax@imc.org>; Fri, 8 Apr 2005 15:59:58 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DK2S9-0007vc-EB; Fri, 08 Apr 2005 22:59:53 +0000 Message-ID: <42570CE3.9000502@franklinmint.fm> Date: Fri, 08 Apr 2005 18:59:47 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood <wunder@verity.com> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> In-Reply-To: <52471BC19BE5F24CD67F7562@diva.verity.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Walter Underwood wrote: > > --On Friday, April 08, 2005 01:33:20 AM -0400 Robert Sayre > <mint@franklinmint.fm> wrote: > >> >> Accessibility is a non-starter absent expert opinion or substantially >> similar formats. Frankly, the notion that remote content constitutes an >> accessibility concern is absurd. Might as well write off the whole Web. > > > No, non-accessible designs are non-starters. ... > > "The power of the Web is in its universality. Access by everyone > regardless of disability is an essential aspect." > -- Tim Berners-Lee > <http://www.w3.org/WAI/> > > Is that expert enough for you? Walter, you are missing my point. You've said it yourself: "Maybe summaries are optional, but not because accessibility is optional."[0] Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg13600.html From owner-atom-syntax@mail.imc.org Fri Apr 8 20:29:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24987 for <atompub-archive@lists.ietf.org>; Fri, 8 Apr 2005 20:29:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j390HG8C011573; Fri, 8 Apr 2005 17:17:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j390HGsv011572; Fri, 8 Apr 2005 17:17:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j390HFcw011559 for <atom-syntax@imc.org>; Fri, 8 Apr 2005 17:17:15 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 0559DFC for <atom-syntax@imc.org>; Fri, 8 Apr 2005 17:17:10 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j390H8ng020582 for <atom-syntax@imc.org>; Fri, 8 Apr 2005 17:17:09 -0700 (PDT) Date: Fri, 08 Apr 2005 17:17:12 -0700 From: Walter Underwood <wunder@verity.com> To: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad Message-ID: <9DACB857278D01A0751EC473@Wunders-Computer.local> In-Reply-To: <42570CE3.9000502@franklinmint.fm> References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> X-Mailer: Mulberry/4.0.0a7 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit --On April 8, 2005 6:59:47 PM -0400 Robert Sayre <mint@franklinmint.fm> wrote: > > Walter, you are missing my point. You've said it yourself: > > "Maybe summaries are optional, but not because accessibility is optional."[0] That was in reply to a proposal to make accessibility an optional profile, and to make summaries required only in that profile. That approach is unacceptable. I would read my comment as "regardless of your position on summaries, accessibility is required." Local textual summaries are rather common on the web. The <a> tag, for example. Current accessibility practice is to make the anchor text understandable out of context. In other words, to make it a summary of the linked resource. Even if the remote resource is text! For the <img> tag, the alt tag is used to provide a local, textual equivalent. Again, this is required practice for accessibility. Same thing for graphs, charts, audio, and video. These are top-level requirements. They fit on the WAI pocket card. There are ten "quick tips" and five of them are about local textual equivalents: <http://www.w3.org/WAI/References/QuickTips/> wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Apr 8 20:42:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25498 for <atompub-archive@lists.ietf.org>; Fri, 8 Apr 2005 20:42:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j390U2I6012069; Fri, 8 Apr 2005 17:30:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j390U2F1012068; Fri, 8 Apr 2005 17:30:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j390U1d4012058 for <atom-syntax@imc.org>; Fri, 8 Apr 2005 17:30:01 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DK3rI-0000IE-VB; Sat, 09 Apr 2005 00:29:57 +0000 Message-ID: <42572200.6020807@franklinmint.fm> Date: Fri, 08 Apr 2005 20:29:52 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood <wunder@verity.com> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> In-Reply-To: <9DACB857278D01A0751EC473@Wunders-Computer.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Walter Underwood wrote: > Local textual summaries are rather common on the web. The <a> tag, for example. > Current accessibility practice is to make the anchor text understandable out > of context. In other words, to make it a summary of the linked resource. > Even if the remote resource is text! > > For the <img> tag, the alt tag is used to provide a local, textual equivalent. > Again, this is required practice for accessibility. Same thing for graphs, > charts, audio, and video. > > These are top-level requirements. They fit on the WAI pocket card. There > are ten "quick tips" and five of them are about local textual equivalents: An Atom Entry without <content> or <summary> still has a <title>. Even more precisely, the link element contains a 'title' attribute. There's two local summaries for you. As I've pointed out already, none of the most current W3C formats *require* textual metadata, from a schematic perspective. This is because accessibility is a social issue, rather than an interop issue. Insisting that constraint in the schema is there for accessibility's sake without explaining the *exact* reason is at best doing accessibility a disservice. I want the to know the precise technical reason for these requirements. No one has given one. We all agree that accessibility is important. Please don't respond to me by saying that accessibility is important. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Apr 9 04:53:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19752 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 04:53:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j398YObQ012836; Sat, 9 Apr 2005 01:34:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j398YOZP012835; Sat, 9 Apr 2005 01:34:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j398YNck012788 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 01:34:23 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 09 Apr 2005 08:34:16 -0000 Received: from p508FE160.dip.t-dialin.net (EHLO [192.168.0.2]) [80.143.225.96] by mail.gmx.net (mp019) with SMTP; 09 Apr 2005 10:34:16 +0200 X-Authenticated: #1915285 Message-ID: <42579382.3040003@gmx.de> Date: Sat, 09 Apr 2005 10:34:10 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax <atom-syntax@imc.org> Subject: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Quoting from Andrew Newton's questions relayed by Scott: <http://www.imc.org/atom-syntax/mail-archive/msg14048.html> > From: Andrew Newton [mailto:andy@xxxxxx] > Sent: Tuesday, April 05, 2005 6:25 PM > To: Scott Hollenbeck > Cc: xml-dir@xxxxxxxx > Subject: Re: [xml-dir] FW: draft-ietf-atompub-format-07.txt is ready for > IETF last call > > > ... > > 2) Section 4.1.3.3 Item 2 > The text: > for example, "<br>" as "<br>". > Is this right? Should it be: > for example, "<br>" as "<br>". We don't need to escape the ">" in text content, as far as I can tell. Are you suggesting to escape it anyway for consistency/readability? > Also, should the "must" in "The HTML markup must be escaped" be a > MUST? I think so. > Should rule 2 have the same note regarding the <DIV> element as rule > 3? What happens if the type is html and the content is all within > <div> .... </div> ? Good question, and an expected one. Lack of consistency here was the reason I made the same suggestion (to either do it for both types, or not to do for it XHTML). > ... I'd like to remind us of another related issue raised a few days ago (<http://www.imc.org/atom-syntax/mail-archive/msg14045.html>). XHTML content is currently restricted to XHTML Basic (see <http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html#rfc.section.4.1.3.3>, <http://www.w3.org/TR/xhtml-basic/>). As far as I can tell, this means *no styling*: - <http://www.w3.org/TR/xhtml-basic/#s1.3.1>: "style" attribute not supported (but "class" is), but - as we require content to be legal within xhtml:div, there's no way to specify CSS information. Although I think it is probably a very good idea to stick with basic markup inside the feed, this seems to introduce an unfortunate disparity between HTML and XHTML, which will result in - people ignoring the XHTML Basic restriction, or, even worse, - people using HTML instead of XHTML to workaround this distinction. I'd propose to go back to XHTML 1.0 "Strict" instead. Best regards, Julian From owner-atom-syntax@mail.imc.org Sat Apr 9 07:07:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27043 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 07:07:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39At9g5059095; Sat, 9 Apr 2005 03:55:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j39At9aA059094; Sat, 9 Apr 2005 03:55:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39At7pf059065 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 03:55:08 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 9 Apr 2005 16:54:41 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Apr 2005 20:54:41 +1000 Subject: content @type From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE7DF191.51267%eric.scheid@ironclad.net.au> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit is there any functional difference between... <content type="xhtml">...</content> and <content type="application/xhtml+xml">...</content> ??? e. From owner-atom-syntax@mail.imc.org Sat Apr 9 07:34:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29629 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 07:34:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39BKeZG070398; Sat, 9 Apr 2005 04:20:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j39BKeIF070397; Sat, 9 Apr 2005 04:20:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39BKbZw070350 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 04:20:38 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 25726 invoked by uid 10); 9 Apr 2005 11:20:31 -0000 Received: (vexira-qq 25693-85F453A3 invoked from network) 09 Apr 2005 13:20:31 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender <fora@annevankesteren.nl>) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 9 Apr 2005 11:20:31 -0000 Message-ID: <4257BA8C.7060802@annevankesteren.nl> Date: Sat, 09 Apr 2005 13:20:44 +0200 From: Anne van Kesteren <fora@annevankesteren.nl> User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid <eric.scheid@ironclad.net.au> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: content @type References: <BE7DF191.51267%eric.scheid@ironclad.net.au> In-Reply-To: <BE7DF191.51267%eric.scheid@ironclad.net.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Eric Scheid wrote: > is there any functional difference between... > > <content type="xhtml">...</content> > > and > > <content type="application/xhtml+xml">...</content> > > ??? We really should have changed this IMHO. -- Anne van Kesteren <http://annevankesteren.nl/> From owner-atom-syntax@mail.imc.org Sat Apr 9 10:30:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12094 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 10:30:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39EHFme003924; Sat, 9 Apr 2005 07:17:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j39EHFX9003923; Sat, 9 Apr 2005 07:17:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39EHEJX003916 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 07:17:15 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:52545 "EHLO [217.140.228.250]" TLS-CIPHER: <none>) by smtp2.dnainternet.net with ESMTP id S1228722AbVDIORN (ORCPT <rfc822;atom-syntax@imc.org>); Sat, 9 Apr 2005 17:17:13 +0300 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <BE7DF191.51267%eric.scheid@ironclad.net.au> References: <BE7DF191.51267%eric.scheid@ironclad.net.au> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <c9e78d859c07d68c4cc587e699a53f93@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen <hsivonen@iki.fi> Subject: Re: content @type Date: Sat, 9 Apr 2005 17:16:55 +0300 To: Atom Syntax <atom-syntax@imc.org> X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Apr 9, 2005, at 13:54, Eric Scheid wrote: > is there any functional difference between... > > <content type="xhtml">...</content> > > and > > <content type="application/xhtml+xml">...</content> > > ??? The first takes a fragment that could live in a div. The latter takes a full XHTML document (html, head, title, body and all). -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Sat Apr 9 16:35:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06226 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 16:35:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39KD9aY022886; Sat, 9 Apr 2005 13:13:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j39KD9W8022885; Sat, 9 Apr 2005 13:13:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39KD7Be022879 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 13:13:08 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j39KFDiN016557; Sat, 9 Apr 2005 16:15:17 -0400 Message-ID: <42583750.6080808@intertwingly.net> Date: Sat, 09 Apr 2005 16:13:04 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> In-Reply-To: <42572200.6020807@franklinmint.fm> 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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > I want the to know the precise technical reason for these requirements. First, I'd like to ask a favor. Please wait 24 hours before replying to this email. In your zeal to filibuster on this particular topic, you have made a number of fallacious and personal attacks. - - - From my point of view, we are approaching the problem from different ends. I am asking "why?", and you are asking "why not?". I want predictability. I want a lack of surprises. You apparently want generality. If in the first 18 months of this email list, there were no messages to this list with a zero length body. In 99.9999% of the feeds I have seen, entries have a summary or content. The few cases I have seen where there have been feeds which (briefly) have not had so much as a summary, there always has been a swift and clear response by the consuming public. When I point that out, you take the opportunity to initiate an ad-hominen attack. I would like to see a feed format in which conformance is not defined by mob justice, but instead (as much as humanly possible) can be determined by a dispassionate RNG schema and/or feedvalidator. Also note that I said "messages to the list with a zero length body". I did not say "messages without a body". I am not an expert on SMTP, but don't believe it is possible to have an email message without a body... the closest one can come is to have a message with a zero length body. Correct me if I am wrong, but I don't see anything in the spec that indicates that content can't be of zero length. Is that sufficient for your needs? Finally, I remember the day when links disappeared from all Radio Userland feeds, to be replaced by guids. A core element replaced by another core element. As links were optional, there wasn't much anybody could say about this. I don't want this to happen to Atom. I want an aggregator author to be able to respond to "but why didn't you display my content" by pointing to an empty content (or summary) element and saying "I displayed what you told me to". More succinctly: if people today view how a given aggregator as feeds without descriptions as a bug to be fixed, then one should either be able to identify one of the following as buggy: the feed, the aggregator, or the format itself. If the answer to this question is indeterminant, then interoperability suffers. - - - I realize that none of these arguments are foolproof. Exceptions can be found. But I will assert that the cumulative effect of each of these arguments is compelling enough to me to rise to the level where I feel a question of "why?" is warranted. Why? What compelling use case would enabling the omission of non-remote, textual content - i.e., not merely providing a zero length content, but the outright omission of same - enable? - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Apr 9 19:05:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16288 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 19:05:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39Ml7mG030418; Sat, 9 Apr 2005 15:47:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j39Ml77M030417; Sat, 9 Apr 2005 15:47:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39Ml6Zm030411 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 15:47:06 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DKOjF-0007Ma-9l; Sat, 09 Apr 2005 22:47:01 +0000 Message-ID: <42585B5F.4040603@franklinmint.fm> Date: Sat, 09 Apr 2005 18:46:55 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby <rubys@intertwingly.net> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> <42583750.6080808@intertwingly.net> In-Reply-To: <42583750.6080808@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Robert Sayre wrote: > >> >> I want the to know the precise technical reason for these requirements. > > > First, I'd like to ask a favor. Please wait 24 hours before replying to > this email. No. > In your zeal to filibuster on this particular topic, Filibuster? What am I trying to delay? I've been trying to discuss this issue, and you've been throwing process objections back at me for weeks. > you > have made a number of fallacious and personal attacks. You and others have made a number of rather unproductive comments as well. At least we can actually discuss the issue now. > From my point of view, we are approaching the problem from different > ends. I am asking "why?", and you are asking "why not?". > > I want predictability. I want a lack of surprises. > > You apparently want generality. > > If in the first 18 months of this email list, there were no messages to > this list with a zero length body. In 99.9999% of the feeds I have > seen, entries have a summary or content. Given the content of this list, that's not surprising. > The few cases I have seen where there have been feeds which (briefly) > have not had so much as a summary, there always has been a swift and > clear response by the consuming public. > > When I point that out, you take the opportunity to initiate an > ad-hominen attack. By pointing to your email with the Gillmor quote? Perhaps you don't understand that answering this email http://www.imc.org/atom-protocol/mail-archive/msg00554.html with this http://www.imc.org/atom-protocol/mail-archive/msg00555.html is obnoxious. So yeah, you're going to get a response that's about you, rather than the issue at hand. Besides, you're wrong. http://*.craigslist.org/*.rss http://memepool.com/memepool.rss http://del.icio.us/rss/tag/atom http://finance.yahoo.com/rss/headline?s=yhoo,goog http://moto.debian.org.tw/rss.php?mode=simple http://www.daypop.com/top/rss.xml http://opensearch.a9.com/spec/opensearchrss/1.0/ http://lists.rootsecure.net/feed/?l=bugtraq&uid=xfuojrfvse http://xanadb.com/rss-lite.xml http://www.intertwingly.net/blog/2004/06/03/Aggregator-utf-16-tests.atom http://newsroom.cisco.com/data/syndication/rss2/news_at_cisco_10nr.xml http://www.apple.com/main/rss/hotnews/pr.rss http://fox.wikis.com/wc.dll?Wiki~WikiRss&details=1 http://feeds.smh.com.au/rssheadlines/top.rss http://www.artsjournal.com/beatrix/rss.xml http://www.drudgereportarchives.com/rss/recap.xml "'dive into mark' publishes 2 feeds, one which contains only titles and one which contains the full text." --http://inessential.com/?comments=1&postid=2057 > I would like to see a feed format in which conformance is not defined by > mob justice, but instead (as much as humanly possible) can be determined > by a dispassionate RNG schema and/or feedvalidator. > > Also note that I said "messages to the list with a zero length body". I > did not say "messages without a body". I am not an expert on SMTP, but > don't believe it is possible to have an email message without a body... > the closest one can come is to have a message with a zero length body. I dunno about SMTP either, but I can look at the IMF spec. from RFC2822, Section 3.5, Overall message syntax: message = (fields / obs-fields) [CRLF body] the body and one of those infamous blank lines are optional. > > Correct me if I am wrong, but I don't see anything in the spec that > indicates that content can't be of zero length. Is that sufficient for > your needs? No. I think there's a difference between those two concepts. http://www.imc.org/atom-protocol/mail-archive/msg00756.html > > Finally, I remember the day when links disappeared from all Radio > Userland feeds, to be replaced by guids. A core element replaced by > another core element. As links were optional, there wasn't much anybody > could say about this. I don't want this to happen to Atom. I want an > aggregator author to be able to respond to "but why didn't you display > my content" by pointing to an empty content (or summary) element and > saying "I displayed what you told me to". How does a co-constraint solve this problem? When that publisher says "why didn't you display my content?", what are they pointing at? An extension element? Why can't the aggregator author just point at the lack of a summary or content element? Secondly, are publishers allowed to complain if an aggregator doesn't show an empty content pane? > More succinctly: if people today view how a given aggregator as feeds > without descriptions as a bug to be fixed, I don't think they do. When the feed is coming from a news site, they might, because they know it would be better like with content. But it's really an editorial issue, you know? > then one should either be > able to identify one of the following as buggy: the feed, the > aggregator, or the format itself. If the answer to this question is > indeterminant, then interoperability suffers. There's a difference between buggy and unsatisfying. > > I realize that none of these arguments are foolproof. Exceptions can be > found. But I will assert that the cumulative effect of each of these > arguments is compelling enough to me to rise to the level where I feel a > question of "why?" is warranted. Why? What compelling use case would > enabling the omission of non-remote, textual content - i.e., not merely > providing a zero length content, but the outright omission of same - > enable? Precise expression in things like the Atom protocol, del.icio.us, daypop, and HTTPLR. Remember how Anil Dash's linkblog had a summary element with just a URI in it, and RSS Bandit showed the web page instead? I feel that this restriction is going to create interop problems of that sort. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Apr 9 19:06:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16331 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 19:06:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39Mmr6G030460; Sat, 9 Apr 2005 15:48:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j39MmrnO030459; Sat, 9 Apr 2005 15:48:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39Mmp6s030452 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 15:48:52 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 36so443074wra for <atom-syntax@imc.org>; Sat, 09 Apr 2005 15:48:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=LoTt+iXWba+Hd01TWPAgBlBGEzpg2f2Ely4OUlK02AIe7bNsdYtGTbatkDU9BHIuLVy5qxjSZX3Ictj7JuTkyJHrQYuMF4kgSMwZyJ2rGqcIvbreYeGRYLd+PoplMyf35hJz4BZribb6hyaqMyMT5nK7LGZPiXfoZVcL1OX5iDI= Received: by 10.54.55.61 with SMTP id d61mr1123953wra; Sat, 09 Apr 2005 15:48:45 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Sat, 9 Apr 2005 15:48:45 -0700 (PDT) Message-ID: <540e37320504091548716b4ee8@mail.gmail.com> Date: Sat, 9 Apr 2005 17:48:45 -0500 From: "Roger B." <rogben@gmail.com> Reply-To: "Roger B." <rogben@gmail.com> To: Sam Ruby <rubys@intertwingly.net> Subject: Re: PaceCoConstraintsAreBad Cc: Atom Syntax <atom-syntax@imc.org> In-Reply-To: <42583750.6080808@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <4254457F.20405@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> <42583750.6080808@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > The few cases I have seen where there have been feeds which (briefly) > have not had so much as a summary, there always has been a swift and > clear response by the consuming public. Sam: In the case of the no-content feeds I've produced over the last few years, the response from the public has been "please keep them coming". The folks in the Tivocommunity forum want me to bring my scraped, title-only feeds back online because the recently added, native forum feeds are kinda useless. That said, I would have no problem at all with providing an empty content element in such a feed, and I'm sure most aggregators would handle it the same way they handle description-free RSS feeds. Of course, cruft doesn't scare me the way it does some folks. -- Roger Benningfield http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Sat Apr 9 19:41:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17745 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 19:41:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39NNI2I032190; Sat, 9 Apr 2005 16:23:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j39NNI42032189; Sat, 9 Apr 2005 16:23:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39NNIn8032183 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 16:23:18 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j39NPM3S003019; Sat, 9 Apr 2005 19:25:25 -0400 Message-ID: <425863E0.9000706@intertwingly.net> Date: Sat, 09 Apr 2005 19:23:12 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roger B." <rogben@gmail.com> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> <42583750.6080808@intertwingly.net> <540e37320504091548716b4ee8@mail.gmail.com> In-Reply-To: <540e37320504091548716b4ee8@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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Roger B. wrote: >>The few cases I have seen where there have been feeds which (briefly) >>have not had so much as a summary, there always has been a swift and >>clear response by the consuming public. > > Sam: In the case of the no-content feeds I've produced over the last > few years, the response from the public has been "please keep them > coming". The folks in the Tivocommunity forum want me to bring my > scraped, title-only feeds back online because the recently added, > native forum feeds are kinda useless. > > That said, I would have no problem at all with providing an empty > content element in such a feed, and I'm sure most aggregators would > handle it the same way they handle description-free RSS feeds. Hi Roger! Yes, I recall you constructively participating in when this was discussed previously, and consensus was declared on the issue by the co-chairs: http://www.imc.org/atom-syntax/mail-archive/msg06649.html Permit me to quote you: > My no-content feeds are distributing such limited info > that there's really no need for anything more than RSS. Trying to force that > kind of thing to work with Atom nets the user nothing (the RSS and Atom > versions would be effectively identical), and blunts Atom's purpose (clearer > specification) in the process. - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Apr 9 19:43:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17800 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 19:43:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39NR4iF032307; Sat, 9 Apr 2005 16:27:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j39NR4ax032306; Sat, 9 Apr 2005 16:27:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39NR3KS032298 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 16:27:03 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j39NQKFN019926; Sun, 10 Apr 2005 00:26:31 +0100 (BST) In-Reply-To: <42585B5F.4040603@franklinmint.fm> References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> <42583750.6080808@intertwingly.net> <42585B5F.4040603@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2b084ff46435743346cd98823b6804bf@mac.com> Content-Transfer-Encoding: 7bit Cc: "Atom-Syntax Syntax'" <atom-syntax@imc.org> From: Graham <dtcd@mac.com> Subject: Re: PaceCoConstraintsAreBad Date: Sun, 10 Apr 2005 00:26:21 +0100 To: mint@franklinmint.fm X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit No one agrees with you Robert. Quit it. Graham From owner-atom-syntax@mail.imc.org Sat Apr 9 19:58:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18274 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 19:58:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39NZltu032653; Sat, 9 Apr 2005 16:35:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j39NZlAK032652; Sat, 9 Apr 2005 16:35:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39NZkh8032643 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 16:35:46 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 2F6C0143 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 16:35:41 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j39NZTng025692 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 16:35:40 -0700 (PDT) Date: Sat, 09 Apr 2005 16:35:33 -0700 From: Walter Underwood <wunder@verity.com> To: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad Message-ID: <4B165100C745EC8C98C632E5@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <42572200.6020807@franklinmint.fm> References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> X-Mailer: Mulberry/4.0.0a7 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit --On April 8, 2005 8:29:52 PM -0400 Robert Sayre <mint@franklinmint.fm> wrote: > > Please don't respond to me by saying that accessibility is important. I would never say that. Required or essential, but not merely important. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sat Apr 9 20:02:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18383 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 20:02:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j39NjTjc033294; Sat, 9 Apr 2005 16:45:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j39NjTGd033293; Sat, 9 Apr 2005 16:45:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by above.proper.com (8.12.11/8.12.9) with SMTP id j39NjS2S033279 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 16:45:28 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 7451 messnum 4222183 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 9 Apr 2005 23:45:22 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail13.svc.cra.dublin.eircom.net (qp 7451) with SMTP; 9 Apr 2005 23:45:22 -0000 Message-ID: <42586910.4030100@dehora.net> Date: Sun, 10 Apr 2005 00:45:20 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham <dtcd@mac.com> CC: mint@franklinmint.fm, "Atom-Syntax Syntax'" <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> <42583750.6080808@intertwingly.net> <42585B5F.4040603@franklinmint.fm> <2b084ff46435743346cd98823b6804bf@mac.com> In-Reply-To: <2b084ff46435743346cd98823b6804bf@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Graham wrote: > > No one agrees with you Robert. Quit it. I suppose then I should state I'm very close to +1 on Robert's position. I think this is an important discussion, insofar as whether the link or the content is primary stuff, and I wouldn't to see it cut short because it became another syndication row. I'm trying to figure out what the problem with optional content is and I can't see it. if I have a link/id for something and a bag of metadata related to that link I don't have to have a content blob for that to be useful or interoperable. In particular the accessibility argument hasn't work for me (I have formal design/human-factors training and practice under my belt, but I'm not claiming to be an accessibility expert viz the Web). cheers Bill From owner-atom-syntax@mail.imc.org Sat Apr 9 20:28:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19482 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 20:28:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A053Qn034507; Sat, 9 Apr 2005 17:05:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3A053Dh034506; Sat, 9 Apr 2005 17:05:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A052jl034488 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 17:05:02 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j3A04tm11582; Sun, 10 Apr 2005 09:04:55 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 4db7d76c_a955_11d9_80af_0030482532aa_19455; Sun, 10 Apr 2005 09:13:02 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO001D69; 10 Apr 05 09:05:58 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 10 Apr 05 09:05:52 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.250.2) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG001D66; 10 Apr 05 09:05:48 +0900 Message-Id: <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 09 Apr 2005 20:28:40 +0900 To: Julian Reschke <julian.reschke@gmx.de>, Atom Syntax <atom-syntax@imc.org> From: Martin Duerst <duerst@it.aoyama.ac.jp> Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-Reply-To: <42579382.3040003@gmx.de> References: <42579382.3040003@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit At 17:34 05/04/09, Julian Reschke wrote: > >Quoting from Andrew Newton's questions relayed by Scott: <http://www.imc.org/atom-syntax/mail-archive/msg14048.html> > >> From: Andrew Newton [mailto:andy@xxxxxx] Sent: Tuesday, April 05, 2005 6:25 PM >> To: Scott Hollenbeck >> Cc: xml-dir@xxxxxxxx >> Subject: Re: [xml-dir] FW: draft-ietf-atompub-format-07.txt is ready for >> IETF last call >> >> ... >> 2) Section 4.1.3.3 Item 2 >> The text: >> for example, "<br>" as "<br>". >> Is this right? Should it be: >> for example, "<br>" as "<br>". > >We don't need to escape the ">" in text content, as far as I can tell. Correct. From http://www.w3.org/TR/REC-xml/#syntax: The right angle bracket (>) MAY be represented using the string ">", and MUST, for compatibility, be escaped using either ">" or a character reference when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section. I'm slightly surprised to get such a comment from the "XML Directorate". But I guess their main job isn't to check lowly syntax details. >Are you suggesting to escape it anyway for consistency/readability? Wouldn't be more readable, in my eyes. >I'd like to remind us of another related issue raised a few days ago (<http://www.imc.org/atom-syntax/mail-archive/msg14045.html>). XHTML content is currently restricted to XHTML Basic (see <http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html#rfc.section.4.1.3.3>, <http://www.w3.org/TR/xhtml-basic/>). As far as I can tell, this means *no styling*: > >- <http://www.w3.org/TR/xhtml-basic/#s1.3.1>: "style" attribute not supported (but "class" is), but >I'd propose to go back to XHTML 1.0 "Strict" instead. Very good point. A very strong +1. Regards, Martin. From owner-atom-syntax@mail.imc.org Sat Apr 9 20:41:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20152 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 20:41:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A0Oh2C035366; Sat, 9 Apr 2005 17:24:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3A0OhWI035365; Sat, 9 Apr 2005 17:24:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3A0OgL3035357 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 17:24:42 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 10 Apr 2005 00:24:35 -0000 Received: from xdsl-213-196-255-53.netcologne.de (EHLO klangraum) [213.196.255.53] by mail.gmx.net (mp002) with SMTP; 10 Apr 2005 02:24:35 +0200 X-Authenticated: #163624 Date: Sun, 10 Apr 2005 02:27:12 +0200 From: "A. Pagaltzis" <pagaltzis@gmx.de> To: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad Message-ID: <20050410002712.GA5851@klangraum> Mail-Followup-To: Atom Syntax <atom-syntax@imc.org> References: <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> <42583750.6080808@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <42583750.6080808@intertwingly.net> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit * Sam Ruby <rubys@intertwingly.net> [2005-04-09 22:30]: > What compelling use case would enabling the omission of > non-remote, textual content - i.e., not merely providing a zero > length content, but the outright omission of same - enable? I have no opinion either way (not that it would have much weight), but I’m curious to know: why are atom:title and atom:link/@title not sufficient a textual non-remote content? Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sat Apr 9 21:16:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21879 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 21:16:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A0pIap036489; Sat, 9 Apr 2005 17:51:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3A0pI5Q036488; Sat, 9 Apr 2005 17:51:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A0pHBR036473 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 17:51:17 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3A0pHXi010700 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 18:51:17 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEP005JMH1GE7@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 09 Apr 2005 18:51:17 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEP00A92H1GO6@mail.sun.net> for atom-syntax@imc.org; Sat, 09 Apr 2005 18:51:16 -0600 (MDT) Date: Sat, 09 Apr 2005 17:51:50 -0700 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: PaceCoConstraintsAreBad In-reply-to: <2b084ff46435743346cd98823b6804bf@mac.com> To: Graham <dtcd@mac.com> Cc: "Atom-Syntax Syntax'" <atom-syntax@imc.org>, mint@franklinmint.fm Message-id: <eed597eee661c350f8389c1731113e63@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> <42583750.6080808@intertwingly.net> <42585B5F.4040603@franklinmint.fm> <2b084ff46435743346cd98823b6804bf@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT On Apr 9, 2005, at 4:26 PM, Graham wrote: > No one agrees with you Robert. Quit it. Well, Robert has not actually favored us with a single clear sentence expressing his point, so I'll try: "The requirement on accessibility grounds for a required <atom:summary> is superfluous, because we have <atom:title> and one required text field is enough." On balance, I would still lean to encouraging the use of <summary/> because I do feel that content-ful feeds are intrinsincally better than link feeds; but only really at a +/- 0 level. That is to say, Rob's position is not that radical or unreasonable. On the other hand, I tend to agree with Sam on the subject of Rob's rhetorical techniques. At the moment, my best judgment of rough consensus would read that most people want to retain the <atom:summary> requirement, but it's clearly not the case that no one agrees with Robert. -Tim From owner-atom-syntax@mail.imc.org Sat Apr 9 21:32:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22483 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 21:32:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A1C5as037858; Sat, 9 Apr 2005 18:12:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3A1C5Yl037857; Sat, 9 Apr 2005 18:12:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A1C28x037722 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 18:12:04 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3A1BdZm001858; Sun, 10 Apr 2005 02:11:44 +0100 (BST) In-Reply-To: <eed597eee661c350f8389c1731113e63@sun.com> References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> <42583750.6080808@intertwingly.net> <42585B5F.4040603@franklinmint.fm> <2b084ff46435743346cd98823b6804bf@mac.com> <eed597eee661c350f8389c1731113e63@sun.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <ef13646ccb0ed5fefbe7978adcce4419@mac.com> Content-Transfer-Encoding: 7bit Cc: "Atom-Syntax Syntax'" <atom-syntax@imc.org> From: Graham <dtcd@mac.com> Subject: Re: PaceCoConstraintsAreBad Date: Sun, 10 Apr 2005 02:11:39 +0100 To: Tim Bray <Tim.Bray@Sun.COM> X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > "The requirement on accessibility grounds for a required > <atom:summary> is superfluous, because we have <atom:title> and one > required text field is enough." There's another solution compatible with this, which is to make title optional (which I've always supported). In most "title only" feeds, the title is usually wordy enough to make better sense as a summary or content. (I'm still very concerned about dealing with the synthenic titles that will be unleashed by Atom in its current state) Graham From owner-atom-syntax@mail.imc.org Sat Apr 9 23:29:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26867 for <atompub-archive@lists.ietf.org>; Sat, 9 Apr 2005 23:29:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A36E5u043184; Sat, 9 Apr 2005 20:06:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3A36EFi043183; Sat, 9 Apr 2005 20:06:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A36CEb043177 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 20:06:14 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DKSm2-0004Fz-4r; Sun, 10 Apr 2005 03:06:10 +0000 Message-ID: <42589818.9070504@franklinmint.fm> Date: Sat, 09 Apr 2005 23:06:00 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray <Tim.Bray@Sun.COM> CC: Graham <dtcd@mac.com>, "Atom-Syntax Syntax'" <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <425495D7.8080206@intertwingly.net> <425496A7.9030002@franklinmint.fm> <42549D8D.5090708@intertwingly.net> <4254A32F.1020601@franklinmint.fm> <425528F7.2090603@intertwingly.net> <42553136.6040906@franklinmint.fm> <42553698.40101@intertwingly.net> <42553A72.2090207@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> <42583750.6080808@intertwingly.net> <42585B5F.4040603@franklinmint.fm> <2b084ff46435743346cd98823b6804bf@mac.com> <eed597eee661c350f8389c1731113e63@sun.com> In-Reply-To: <eed597eee661c350f8389c1731113e63@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Apr 9, 2005, at 4:26 PM, Graham wrote: > >> No one agrees with you Robert. Quit it. > > > Well, Robert has not actually favored us with a single clear sentence > expressing his point, so I'll try: The 10th bullet point of section 4.1.2 should read: atom:entry elements MUST contain an atom:summary element in either of the following cases: * the atom:entry contains an atom:content that has a "src" attribute (and is thus empty). * the atom:entry contains content that is encoded in Base64; i.e. the "type" attribute of atom:content is a MIME media type [RFC2045] and does not begin with "text/" nor end with "+xml". > "The requirement on accessibility grounds for a required <atom:summary> > is superfluous, because we have <atom:title> and one required text field > is enough." > > On balance, I would still lean to encouraging the use of <summary/> > because I do feel that content-ful feeds are intrinsincally better than > link feeds; but only really at a +/- 0 level. Are legions of people complaining about del.icio.us and craigslist? Should we use our spec to imply publishers must provide text? An app would handle an empty content element the same way it would an absent one. Thus, the current spec is concerned with advocacy, not interop. > That is to say, Rob's > position is not that radical or unreasonable. On the other hand, I tend > to agree with Sam on the subject of Rob's rhetorical techniques. Yes, well, what did it take to get the subject addressed in a technical manner? I've tried a variety of rhetorical techniques. > At the > moment, my best judgment of rough consensus would read that most people > want to retain the <atom:summary> requirement, but it's clearly not the > case that no one agrees with Robert. RFC 2822: Optional body RSS 0.90: Required title, Required link, No description RSS 0.91: Required title, Required link, Optional description RSS 0.92: Optional title, Optional link, Optional description RSS 1.0: Required title, Required link, Optional description RSS 2.0: Optional title, Optional link, Optional description Atom 0.3: Required title, Required link, Optional summary and content Robert Sayre From owner-atom-syntax@mail.imc.org Sun Apr 10 00:02:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28150 for <atompub-archive@lists.ietf.org>; Sun, 10 Apr 2005 00:02:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A3gmEw044345; Sat, 9 Apr 2005 20:42:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3A3gmUv044344; Sat, 9 Apr 2005 20:42:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A3glQe044338 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 20:42:47 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DKTLQ-0004Y7-PS; Sun, 10 Apr 2005 03:42:44 +0000 Message-ID: <4258A0AB.4020902@franklinmint.fm> Date: Sat, 09 Apr 2005 23:42:35 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby <rubys@intertwingly.net> CC: "Roger B." <rogben@gmail.com>, Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad References: <4254457F.20405@franklinmint.fm> <4255A185.4030608@intertwingly.net> <4255A489.7020003@franklinmint.fm> <c9e9bff72541aa8faaef8e0e9abc9879@sun.com> <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> <42583750.6080808@intertwingly.net> <540e37320504091548716b4ee8@mail.gmail.com> <425863E0.9000706@intertwingly.net> In-Reply-To: <425863E0.9000706@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > Hi Roger! Yes, I recall you constructively participating in when this > was discussed previously, and consensus was declared on the issue by the > co-chairs: Ah, a process argument. If the chairs consider this discussion out of order, they can declare it so. I will respect that. > http://www.imc.org/atom-syntax/mail-archive/msg06649.html > > Permit me to quote you: > >> My no-content feeds are distributing such limited info >> that there's really no need for anything more than RSS. Trying to >> force that >> kind of thing to work with Atom nets the user nothing (the RSS and Atom >> versions would be effectively identical), and blunts Atom's purpose >> (clearer >> specification) in the process. That's not really true, isn't it? You see, an Atom feed would be required to have an id, a date, a link, and a title. Which RSS dialect can say that? Robert Sayre From owner-atom-syntax@mail.imc.org Sun Apr 10 01:07:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01709 for <atompub-archive@lists.ietf.org>; Sun, 10 Apr 2005 01:07:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A4n13T046949; Sat, 9 Apr 2005 21:49:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3A4n1A3046948; Sat, 9 Apr 2005 21:49:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A4n02q046942 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 21:49:01 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 10 Apr 2005 10:48:53 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 10 Apr 2005 14:48:54 +1000 Subject: text/plain Base64? From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE7EED56.5143B%eric.scheid@ironclad.net.au> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit I know content with @type != text/* or */xml *+xml MUST be Base64 encoded, but what about content with those magic types ... should the spec say that they MUST NOT be Base64 encoded? How would I send plain text which contains control codes (eg <FF>, <BELL>, etc) in a <content> element? Am I forced to put them in a separate file and refer via @src? Even if they are very short pieces of text? e. From owner-atom-syntax@mail.imc.org Sun Apr 10 01:10:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02037 for <atompub-archive@lists.ietf.org>; Sun, 10 Apr 2005 01:10:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A4qbDd047032; Sat, 9 Apr 2005 21:52:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3A4qbEr047031; Sat, 9 Apr 2005 21:52:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A4qa4T047025 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 21:52:36 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 10 Apr 2005 10:52:33 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 10 Apr 2005 14:52:34 +1000 Subject: Re: PaceCoConstraintsAreBad From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE7EEE32.5143D%eric.scheid@ironclad.net.au> In-Reply-To: <42589818.9070504@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 10/4/05 1:06 PM, "Robert Sayre" <mint@franklinmint.fm> wrote: > An app would handle an empty content element the same way it would an > absent one. would it? could it be reasonable that an empty element gets displayed as empty, but an absent element triggers a fall back mechanism (eg. use the <summary> element, and if that is missing display the <link rel=alternate> resource? e. From owner-atom-syntax@mail.imc.org Sun Apr 10 02:46:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27574 for <atompub-archive@lists.ietf.org>; Sun, 10 Apr 2005 02:46:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A6R9t6082936; Sat, 9 Apr 2005 23:27:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3A6R9sG082935; Sat, 9 Apr 2005 23:27:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A6Qxqi082858 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 23:27:00 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3A6QxXi004390 for <atom-syntax@imc.org>; Sun, 10 Apr 2005 00:26:59 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEP005PLWKZE7@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 10 Apr 2005 00:26:59 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEP00HRYWKXJS@mail.sun.net> for atom-syntax@imc.org; Sun, 10 Apr 2005 00:26:57 -0600 (MDT) Date: Sat, 09 Apr 2005 23:27:31 -0700 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: text/plain Base64? In-reply-to: <BE7EED56.5143B%eric.scheid@ironclad.net.au> To: Eric Scheid <eric.scheid@ironclad.net.au> Cc: Atom Syntax <atom-syntax@imc.org> Message-id: <094ba81854e739b7d32e26c8acd00165@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <BE7EED56.5143B%eric.scheid@ironclad.net.au> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT On Apr 9, 2005, at 9:48 PM, Eric Scheid wrote: > > > I know content with @type != text/* or */xml *+xml MUST be Base64 > encoded, > but what about content with those magic types ... should the spec say > that > they MUST NOT be Base64 encoded? > > How would I send plain text which contains control codes (eg <FF>, > <BELL>, > etc) in a <content> element? You wouldn't be able to send them. I see this as another benefit of Atom. Seriously, FF and BELL are exceptions in the menagerie of tiny-code-point crufty-ASCII-legacy in that they actually have semantics. But then there's ENQ and ACK and NAK and ETB and their misbegotten friends, the presence of which in your data is a strong signal that something is seriously broken. XML 1.1 would allow you to use these things, but this advantage has failed to win XML 1.1 much of a market presence. Which I take as indicative. -Tim From owner-atom-syntax@mail.imc.org Sun Apr 10 02:46:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27606 for <atompub-archive@lists.ietf.org>; Sun, 10 Apr 2005 02:46:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A6Qbu8082736; Sat, 9 Apr 2005 23:26:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3A6QbUJ082735; Sat, 9 Apr 2005 23:26:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A6Qa3R082724 for <atom-syntax@imc.org>; Sat, 9 Apr 2005 23:26:37 -0700 (PDT) (envelope-from jtauber@jtauber.com) Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 9E92CC71884 for <atom-syntax@imc.org>; Sun, 10 Apr 2005 02:26:35 -0400 (EDT) X-Sasl-enc: dRM7a1bvuPVSl+9OhkESlA 1113114395 Received: from [64.134.59.233] (dhcp64-134-59-233.burl.bos.wayport.net [64.134.59.233]) by frontend2.messagingengine.com (Postfix) with ESMTP id 4DD1F56F785 for <atom-syntax@imc.org>; Sun, 10 Apr 2005 02:26:34 -0400 (EDT) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 10 Apr 2005 02:26:32 -0400 Subject: Re: PaceCoConstraintsAreBad From: James Tauber <jtauber@jtauber.com> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE7E3F58.1F80B%jtauber@jtauber.com> In-Reply-To: <BE7EEE32.5143D%eric.scheid@ironclad.net.au> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 10/4/05 12:52 AM, "Eric Scheid" <eric.scheid@ironclad.net.au> wrote: > could it be reasonable that an empty element gets displayed as empty, but an > absent element triggers a fall back mechanism (eg. use the <summary> > element, and if that is missing display the <link rel=alternate> resource? The first RSS Reader I used (SharpReader) would retrieve the linked resource and display that in the absence of content (and presumably of summary too if that distinction had been made at the time). I enjoyed reading that way and so, as a result, the first feed I offered for my own blog was a titles-only feed. While I have long since added a full-content feed, I continue to get new subscribers to the titles-only feed. James -- James Tauber http://jtauber.com/ journeyman of some http://jtauber.com/blog/ From owner-atom-syntax@mail.imc.org Sun Apr 10 05:51:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06576 for <atompub-archive@lists.ietf.org>; Sun, 10 Apr 2005 05:51:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A9UYrI043190; Sun, 10 Apr 2005 02:30:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3A9UYtm043189; Sun, 10 Apr 2005 02:30:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A9UXUW043175 for <atom-syntax@imc.org>; Sun, 10 Apr 2005 02:30:34 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1DKYlv-0006Il-00; Sun, 10 Apr 2005 10:30:27 +0100 Date: Sun, 10 Apr 2005 10:30:27 +0100 From: James Aylett <james@tartarus.org> To: Atom Syntax <atom-syntax@imc.org> Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Message-ID: <20050410093027.GA6139@tartarus.org> Mail-Followup-To: James Aylett <james@tartarus.org>, Atom Syntax <atom-syntax@imc.org> References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> On Sat, Apr 09, 2005 at 08:28:40PM +0900, Martin Duerst wrote: > >> 2) Section 4.1.3.3 Item 2 > >> The text: > >> for example, "<br>" as "<br>". > >> Is this right? Should it be: > >> for example, "<br>" as "<br>". > > > >We don't need to escape the ">" in text content, as far as I can tell. > > Correct. From http://www.w3.org/TR/REC-xml/#syntax: > The right angle bracket (>) MAY be represented using the string ">", > and MUST, for compatibility, be escaped using either ">" or a character > reference when it appears in the string "]]>" in content, when that string > is not marking the end of a CDATA section. > > >Are you suggesting to escape it anyway for consistency/readability? > > Wouldn't be more readable, in my eyes. OTOH since someone has asked the question who presumably is fairly knowledgable about XML, and most people people are not, would it be worth putting a brief comment pointing to the appropriate section of the XML TR? "Note that in XML the right angle bracket (>) need not be entity escaped in many common situations. See <REF>." Or something like that. James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Sun Apr 10 06:01:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07328 for <atompub-archive@lists.ietf.org>; Sun, 10 Apr 2005 06:01:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A9cwls045978; Sun, 10 Apr 2005 02:38:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3A9cwVv045977; Sun, 10 Apr 2005 02:38:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ixion.tartarus.org (ixion.tartarus.org [62.197.40.170]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3A9cvgi045965 for <atom-syntax@imc.org>; Sun, 10 Apr 2005 02:38:57 -0700 (PDT) (envelope-from james@ixion.tartarus.org) Received: from james by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) for atom-syntax@imc.org id 1DKYu8-0006QI-00; Sun, 10 Apr 2005 10:38:56 +0100 Date: Sun, 10 Apr 2005 10:38:56 +0100 From: James Aylett <james@tartarus.org> To: "Atom-Syntax Syntax'" <atom-syntax@imc.org> Subject: Re: PaceCoConstraintsAreBad Message-ID: <20050410093856.GB6139@tartarus.org> Mail-Followup-To: James Aylett <james@tartarus.org>, Atom-Syntax Syntax' <atom-syntax@imc.org> References: <425617A0.4010008@franklinmint.fm> <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> <42583750.6080808@intertwingly.net> <42585B5F.4040603@franklinmint.fm> <2b084ff46435743346cd98823b6804bf@mac.com> <eed597eee661c350f8389c1731113e63@sun.com> <42589818.9070504@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42589818.9070504@franklinmint.fm> User-Agent: Mutt/1.3.28i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> On Sat, Apr 09, 2005 at 11:06:00PM -0400, Robert Sayre wrote: [Text proposal] > The 10th bullet point of section 4.1.2 should read: > > atom:entry elements MUST contain an atom:summary element in either of > the following cases: > > * the atom:entry contains an atom:content that has a "src" attribute > (and is thus empty). FWIW, for clarity I would favour: '... has a "src" attribute (and is thus itself empty).' The 'itself' I feel allows the 'empty' assertion to govern atom:content, not the src attribute, without ambiguity. (Overall I'm neutral on this discussion, but I'd like the wording clear whatever is chosen :-) > * the atom:entry contains content that is encoded in Base64; i.e. > the "type" attribute of atom:content is a MIME media type > [RFC2045] and does not begin with "text/" nor end with "+xml". James -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From owner-atom-syntax@mail.imc.org Sun Apr 10 06:56:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09750 for <atompub-archive@lists.ietf.org>; Sun, 10 Apr 2005 06:56:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3AAbvci066941; Sun, 10 Apr 2005 03:37:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3AAbvau066939; Sun, 10 Apr 2005 03:37:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3AAbtib066892 for <atom-syntax@imc.org>; Sun, 10 Apr 2005 03:37:56 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 10 Apr 2005 10:37:49 -0000 Received: from xdsl-213-196-254-147.netcologne.de (EHLO klangraum) [213.196.254.147] by mail.gmx.net (mp011) with SMTP; 10 Apr 2005 12:37:49 +0200 X-Authenticated: #163624 Date: Sun, 10 Apr 2005 12:40:25 +0200 From: "A. Pagaltzis" <pagaltzis@gmx.de> To: "Atom-Syntax Syntax'" <atom-syntax@imc.org> Cc: James Aylett <james@tartarus.org> Subject: Re: PaceCoConstraintsAreBad Message-ID: <20050410104025.GA9178@klangraum> Mail-Followup-To: Atom-Syntax Syntax' <atom-syntax@imc.org>, James Aylett <james@tartarus.org> References: <52471BC19BE5F24CD67F7562@diva.verity.com> <42570CE3.9000502@franklinmint.fm> <9DACB857278D01A0751EC473@Wunders-Computer.local> <42572200.6020807@franklinmint.fm> <42583750.6080808@intertwingly.net> <42585B5F.4040603@franklinmint.fm> <2b084ff46435743346cd98823b6804bf@mac.com> <eed597eee661c350f8389c1731113e63@sun.com> <42589818.9070504@franklinmint.fm> <20050410093856.GB6139@tartarus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050410093856.GB6139@tartarus.org> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit * James Aylett <james@tartarus.org> [2005-04-10 11:55]: > On Sat, Apr 09, 2005 at 11:06:00PM -0400, Robert Sayre wrote: > > * the atom:entry contains an atom:content that has a "src" > > attribute (and is thus empty). > > FWIW, for clarity I would favour: > > '... has a "src" attribute (and is thus itself empty).' > > The 'itself' I feel allows the 'empty' assertion to govern > atom:content, not the src attribute, without ambiguity. To me that actually sounds even more ambiguous. I suggest simply omitting the parentheses, which would seem to let the “and†more clearly qualify the “that,†to my mind. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sun Apr 10 10:58:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25334 for <atompub-archive@lists.ietf.org>; Sun, 10 Apr 2005 10:58:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3AEeNGl017648; Sun, 10 Apr 2005 07:40:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3AEeNwU017647; Sun, 10 Apr 2005 07:40:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3AEeIdl017639 for <atom-syntax@imc.org>; Sun, 10 Apr 2005 07:40:18 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3AEeHK2006945 for <atom-syntax@imc.org>; Sun, 10 Apr 2005 08:40:18 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEQ00466JF5C9@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 10 Apr 2005 08:40:17 -0600 (MDT) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEQ000NIJF47R@mail.sun.net> for atom-syntax@imc.org; Sun, 10 Apr 2005 08:40:17 -0600 (MDT) Date: Sun, 10 Apr 2005 07:40:51 -0700 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-reply-to: <20050410093027.GA6139@tartarus.org> To: James Aylett <james@tartarus.org> Cc: Atom Syntax <atom-syntax@imc.org> Message-id: <2a597660ab64d7fefc0d941aa59bbacd@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <20050410093027.GA6139@tartarus.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT On Apr 10, 2005, at 2:30 AM, James Aylett wrote: > OTOH since someone has asked the question who presumably is fairly > knowledgable about XML, and most people people are not, would it be > worth putting a brief comment pointing to the appropriate section of > the XML TR? > > "Note that in XML the right angle bracket (>) need not be entity > escaped in many common situations. See <REF>." I think this is really extraneous to our spec. I tend to agree with Martin that > is more legible than >, but many software packages will always output > because of the small but nonzero possibility of something like this happening: if (a[b[i]]>0) { c++; } // yer not well-formed -Tim From owner-atom-syntax@mail.imc.org Sun Apr 10 16:50:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18168 for <atompub-archive@lists.ietf.org>; Sun, 10 Apr 2005 16:50:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3AKbKIN048485; Sun, 10 Apr 2005 13:37:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3AKbKOV048484; Sun, 10 Apr 2005 13:37:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3AKbJCe048477 for <atom-syntax@imc.org>; Sun, 10 Apr 2005 13:37:19 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DKjBD-0007bX-8x; Sun, 10 Apr 2005 20:37:15 +0000 Message-ID: <42598E73.4080708@franklinmint.fm> Date: Sun, 10 Apr 2005 16:37:07 -0400 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?windows-1252?Q?Bill_de_h=D3ra?= <bill@dehora.net> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: Obs on format-07 References: <425491E7.3020605@dehora.net> In-Reply-To: <425491E7.3020605@dehora.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Bill de hÓra wrote: ... > > ** ABNF > > Drop. > ... > reason: ABNF is used in one place: > > 4.2.9.2 The "rel" Attribute, p1 > > and referred to in 3.3. It's incidental enough to be dropped. I agree with this one now. The other specs use the older ABNF spec anyway. > > ** Figures > > Please add figure captions for all samples, bnf and rnc fragments. If > you require someone to do this, I will do it. I'm having trouble seeing the benefit here. They might work well in the HTML version, but I don't think they do in the text version. Could you show me an example where it would help the text version? Robert Sayre From owner-atom-syntax@mail.imc.org Sun Apr 10 17:43:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20628 for <atompub-archive@lists.ietf.org>; Sun, 10 Apr 2005 17:43:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3ALSHFQ051028; Sun, 10 Apr 2005 14:28:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3ALSH8o051027; Sun, 10 Apr 2005 14:28:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3ALSFxv051006 for <atom-syntax@imc.org>; Sun, 10 Apr 2005 14:28:16 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 45977 messnum 4225286 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 10 Apr 2005 21:28:09 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail13.svc.cra.dublin.eircom.net (qp 45977) with SMTP; 10 Apr 2005 21:28:09 -0000 Message-ID: <42599A67.7080608@dehora.net> Date: Sun, 10 Apr 2005 22:28:07 +0100 From: =?windows-1252?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: Obs on format-07 References: <425491E7.3020605@dehora.net> <42598E73.4080708@franklinmint.fm> In-Reply-To: <42598E73.4080708@franklinmint.fm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Robert Sayre wrote: > > Bill de hÓra wrote: > > ... > >> >> ** ABNF >> >> Drop. >> > ... > >> reason: ABNF is used in one place: >> >> 4.2.9.2 The "rel" Attribute, p1 >> >> and referred to in 3.3. It's incidental enough to be dropped. > > > I agree with this one now. The other specs use the older ABNF spec anyway. > >> >> ** Figures >> >> Please add figure captions for all samples, bnf and rnc fragments. If >> you require someone to do this, I will do it. > > > I'm having trouble seeing the benefit here. They might work well in the > HTML version, but I don't think they do in the text version. Could you > show me an example where it would help the text version? I can look at a caption to tell me it's a rnc fragment, without doing a double or treble take. There are captions in the spec anyway, just not 'marked up' as such: [[[ 3.1.1.2 HTML Example atom:title with HTML content: ... <title type="html"> Less: <em> &lt; </em> ... ]]] But truth be told, I see no need to justify their inclusion, any more than one would need to justify the inclusion of a TOC or page numbers. cheers Bill From owner-atom-syntax@mail.imc.org Sun Apr 10 17:51:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21233 for ; Sun, 10 Apr 2005 17:51:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3ALYDA5051351; Sun, 10 Apr 2005 14:34:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3ALYD5Y051350; Sun, 10 Apr 2005 14:34:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3ALY8TZ051337; Sun, 10 Apr 2005 14:34:08 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <42598E73.4080708@franklinmint.fm> References: <425491E7.3020605@dehora.net> <42598E73.4080708@franklinmint.fm> Date: Sun, 10 Apr 2005 14:34:05 -0700 To: mint@franklinmint.fm, Bill de =?iso-8859-1?Q?h=D3ra?= From: Paul Hoffman Subject: Re: Obs on format-07 Cc: Atom Syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 4:37 PM -0400 4/10/05, Robert Sayre wrote: >>** Figures >> >>Please add figure captions for all samples, bnf and rnc fragments. >>If you require someone to do this, I will do it. > >I'm having trouble seeing the benefit here. They might work well in >the HTML version, but I don't think they do in the text version. I agree with Robert here. If the samples and fragments appear just after the paragraph talking about them, I would find the figure names more distracting than useful. I didn't trip over anything when reading the latest draft. >Could you show me an example where it would help the text version? Agree: please point to where they might be useful. A little judicious use is fine, but having every fragment labelled would probably be overkill. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Apr 11 15:39:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13105 for ; Mon, 11 Apr 2005 15:39:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BJJJNs061500; Mon, 11 Apr 2005 12:19:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3BJJJqn061499; Mon, 11 Apr 2005 12:19:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BJJIAZ061486 for ; Mon, 11 Apr 2005 12:19:18 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.166.29]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id A7AD3A320D; Mon, 11 Apr 2005 15:19:17 -0400 (EDT) In-Reply-To: <5b29c515110e3fbee7186e18a47661c0@mnot.net> References: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> <5b29c515110e3fbee7186e18a47661c0@mnot.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <642fd2e434d5a2e65570312562091642@mnot.net> Content-Transfer-Encoding: 7bit Cc: Tim Bray X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: ABNF, Validity, Relation Registry [was: AD Review Comments and Questions: draft-ietf-atompub-format-07] Date: Mon, 11 Apr 2005 12:19:12 -0700 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Does anybody have feedback on the suggestions/questions below? If I don't get any feedback on the ABNF or validity discussions, I'll proceed as outlined. I think there needs to be *some* feedback regarding the link relation registry; I'm proposing substantial changes there (my preferred approach is to change it so that IETF Consensus, rather than IESG approval, is required to register a link relation). Anybody have thoughts? On Apr 6, 2005, at 5:13 PM, Mark Nottingham wrote: >>> Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt >>> instead >>> of RFC 2234 and confirm that everything that was valid before is >>> still >>> valid. The IESG approved this document as a Draft Standard last >>> week. >> >> Rob/Mark? > > Hmm. As far as I can tell, the *only* place where we actually define a > rule is 4.2.9.2, and that's just combining two rules by reference. I > wonder if we can save complexity here (and remove one normative > reference) by just doing this in prose; the text is currently: > [[[ > ABNF for the "rel" attribute: > > rel_attribute = isegment-nz-nc / IRI > > The value of "rel" MUST be string that is non-empty, does not > contain > any colon (":") characters, and matches the "isegment-nz-nc" or > "IRI" > ABNF forms in [RFC3987]. > ]]] > > So it seems like the ABNF is extraneous here, and if we dropped it, we > could also drop the reference. > > (Just a suggestion, I'm also happy to change the reference.) >>> Section 2 describes a requirement for well-formedness, but it doesn't >>> mention validity. I suspect that validity isn't a requirement given >>> that >>> the RELAX NG schema is informative, but it would be better if a >>> specific >>> statement were included to note that validity is not a requirement. >> >> Hmm, I would say that validity isn't a requirement because the >> syntactic constraints are (we think) fully given in the text. The >> group consciously decided not to make the schema normative, for that >> reason. We do currently say that the schema is non-normative; having >> said that, a statement that there is no DTD and no validity >> requirement couldn't hurt. Rob/Mark? > > Suggest adding the following after "Atom Documents MUST be well-formed > XML."; > > [[[This specification does not define a DTD for Atom Documents, and > hence does not require them to be valid (in the sense used by XML).]]] >>> Section 7.1: what process is the IESG supposed to use to review >>> registration >>> requests? Please see section 2 of RFC 2434/BCP 26 for mechanisms >>> that might >>> be used and please specify one in the document. > > Hmm. Looking over this, I wonder why IESG approval was the path > chosen, given that URIs can also be used. It seems like the natural > bar for getting something into the registry would be IETF consensus; > can someone comment as to why this was chosen (I didn't participate in > the discussions surrounding this registry)? > > If we remain on an IESG approval path, such text would probably look > something like; "Registered link relations SHOULD be widely > implemented, since they effectively serve as shortcuts for URIs; as > such, proposals need to demonstrate that there is community value in > minting such a shortcut." > Also, it may be good to replace the list of suggested topics with a > registration template, to get more uniformity and make IANA's life > easier (sorry I didn't notice this earlier). > Finally, has someone doubled-checked with IANA that the > "http://www.iana.org/assignments/relation/" URI is available and > appropriate? -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Mon Apr 11 15:44:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13620 for ; Mon, 11 Apr 2005 15:44:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BJNvQP062220; Mon, 11 Apr 2005 12:23:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3BJNv7Z062219; Mon, 11 Apr 2005 12:23:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BJNunO062213 for ; Mon, 11 Apr 2005 12:23:56 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-2 ([129.148.9.73]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j3BJNuJx027394 for ; Mon, 11 Apr 2005 12:23:56 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IES00B01R7IFY@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Mon, 11 Apr 2005 15:23:56 -0400 (EDT) Received: from localhost (vpn-129-150-35-167.Central.Sun.COM [129.150.35.167]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IES00B5BR7VW0@bur-mail1.east.sun.com> for atom-syntax@imc.org; Mon, 11 Apr 2005 15:23:56 -0400 (EDT) Received: from ndw by localhost with local (Exim 4.50) id 1DL4Vm-0003DO-Py for atom-syntax@imc.org; Mon, 11 Apr 2005 15:23:54 -0400 X-URL: http://nwalsh.com/ Date: Mon, 11 Apr 2005 15:23:54 -0400 From: Norman Walsh Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-reply-to: <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> To: atom-syntax@imc.org Message-id: <87k6n9rub9.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable [ discussion of basic vs. strict and validity wrt xhtml/html elided ] | >I'd propose to go back to XHTML 1.0 "Strict" instead. | | Very good point. A very strong +1. Do we really want to go here? I hadn't interpreted the Atom format spec as requiring that the content of the xhtml:div be valid according to any particular schema. If that's our intent, I think this paragraph needs to be reworded to make that clearer: 3. If the value of "type" is "xhtml", the content of atom:content MUST be a single XHTML div element [W3C.REC-xhtml-basic-20001219]. The XHTML div MUST contain XHTML text and markup that could validly appear within an XHTML div element. I don't naturally associate the "MUST" in that last sentence with "validity" in the sense of "MUST be valid". Perhaps I should. But I hope not. I don't really want to have to rev the Atom format spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0 stuff in my xhtml:div elements and let the down-stream appliation work it out. At least that's what I think I want. Be seeing you, norm =2D-=20 Norman Walsh | Everything should be made as simple as http://nwalsh.com/ | possible, but no simpler. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCWs7KOyltUcwYWjsRAnmIAJ9mlbVHtDghuN/YieRwQjs6tmKfngCdGtJG s/gH+Gldt2BukP7FR0QHOAA= =AWy4 -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Mon Apr 11 16:04:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16024 for ; Mon, 11 Apr 2005 16:04:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BJgR3D066121; Mon, 11 Apr 2005 12:42:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3BJgRkJ066120; Mon, 11 Apr 2005 12:42:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BJgPkl066098 for ; Mon, 11 Apr 2005 12:42:26 -0700 (PDT) (envelope-from joe.gregorio@gmail.com) Received: by zproxy.gmail.com with SMTP id 13so744971nzn for ; Mon, 11 Apr 2005 12:42:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=tGxSjujm8ydOfx/kX0VU/e3VNRwNnVxLx3HphBoGeqLWYJiPjIAR9zY0nmOR80b9nkXNVTu2ldVC1ahninMR0DW7aA7mBELsflHDqDlIpGd4y481iUr+mf/9YKgKQkhW7syJ83JQsI2yhkHzL9KRvOyGLVngPuxh5RwofdlE75w= Received: by 10.36.23.1 with SMTP id 1mr206981nzw; Mon, 11 Apr 2005 12:42:19 -0700 (PDT) Received: by 10.36.65.13 with HTTP; Mon, 11 Apr 2005 12:42:19 -0700 (PDT) Message-ID: <3f1451f505041112424df2bf44@mail.gmail.com> Date: Mon, 11 Apr 2005 15:42:19 -0400 From: Joe Gregorio Reply-To: Joe Gregorio To: Norman Walsh Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Cc: atom-syntax@imc.org In-Reply-To: <87k6n9rub9.fsf@nwalsh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 11, 2005 3:23 PM, Norman Walsh wrote: > I don't really want to have to rev the Atom format > spec when XHTML 2.0 comes out. +1 -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Mon Apr 11 16:04:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16064 for ; Mon, 11 Apr 2005 16:04:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BJjtUd066848; Mon, 11 Apr 2005 12:45:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3BJjtH4066847; Mon, 11 Apr 2005 12:45:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BJjs59066817 for ; Mon, 11 Apr 2005 12:45:55 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 4357 invoked by uid 10); 11 Apr 2005 19:45:48 -0000 Received: (vexira-qq 04336-E6F8E267 invoked from network) 11 Apr 2005 21:45:47 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 11 Apr 2005 19:45:47 -0000 Message-ID: <425AD3EE.5070701@annevankesteren.nl> Date: Mon, 11 Apr 2005 21:45:50 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Walsh CC: atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> In-Reply-To: <87k6n9rub9.fsf@nwalsh.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > But I hope not. I don't really want to have to rev the Atom format > spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0 > stuff in my xhtml:div elements and let the down-stream appliation work > it out. XHTML 2 does have a different namespace. Future versions of XHTML may or may not have a DIV element. I agree that this might be out the scope of Atom, but it does create problems for interoparability. Also, what do you expect feed readers to support for XHTML versions, etc. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon Apr 11 16:23:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19881 for ; Mon, 11 Apr 2005 16:23:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BK7mWl070769; Mon, 11 Apr 2005 13:07:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3BK7mUu070768; Mon, 11 Apr 2005 13:07:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3BK7lHh070748 for ; Mon, 11 Apr 2005 13:07:47 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 70055 messnum 269790 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 11 Apr 2005 20:07:41 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail03.svc.cra.dublin.eircom.net (qp 70055) with SMTP; 11 Apr 2005 20:07:41 -0000 Message-ID: <425AD909.4060703@dehora.net> Date: Mon, 11 Apr 2005 21:07:37 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: Atom Syntax , Tim Bray Subject: Re: ABNF, Validity, Relation Registry [was: AD Review Comments and Questions: draft-ietf-atompub-format-07] References: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> <5b29c515110e3fbee7186e18a47661c0@mnot.net> <642fd2e434d5a2e65570312562091642@mnot.net> In-Reply-To: <642fd2e434d5a2e65570312562091642@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: >> Hmm. As far as I can tell, the *only* place where we actually define a >> rule is 4.2.9.2, and that's just combining two rules by reference. I >> wonder if we can save complexity here (and remove one normative >> reference) by just doing this in prose; the text is currently: >> [[[ >> ABNF for the "rel" attribute: >> >> rel_attribute = isegment-nz-nc / IRI >> >> The value of "rel" MUST be string that is non-empty, does not contain >> any colon (":") characters, and matches the "isegment-nz-nc" or "IRI" >> ABNF forms in [RFC3987]. >> ]]] >> >> So it seems like the ABNF is extraneous here, and if we dropped it, we >> could also drop the reference. >> >> (Just a suggestion, I'm also happy to change the reference.) I commented on this and felt it could be dropped as could an ABNF ref in in 3 (3.3?) >> Suggest adding the following after "Atom Documents MUST be well-formed >> XML."; >> >> [[[This specification does not define a DTD for Atom Documents, and >> hence does not require them to be valid (in the sense used by XML).]]] +1 cheers Bill From owner-atom-syntax@mail.imc.org Mon Apr 11 16:26:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20438 for ; Mon, 11 Apr 2005 16:26:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BKEKMo071666; Mon, 11 Apr 2005 13:14:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3BKEJOw071665; Mon, 11 Apr 2005 13:14:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3BKEJbZ071651 for ; Mon, 11 Apr 2005 13:14:19 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 85823 messnum 11068145 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 11 Apr 2005 20:14:13 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail11.svc.cra.dublin.eircom.net (qp 85823) with SMTP; 11 Apr 2005 20:14:13 -0000 Message-ID: <425ADA91.5010009@dehora.net> Date: Mon, 11 Apr 2005 21:14:09 +0100 From: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren CC: Norman Walsh , atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> In-Reply-To: <425AD3EE.5070701@annevankesteren.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > > Norman Walsh wrote: > >> But I hope not. I don't really want to have to rev the Atom format >> spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0 >> stuff in my xhtml:div elements and let the down-stream appliation work >> it out. > > > XHTML 2 does have a different namespace. Future versions of XHTML may or > may not have a DIV element. I agree that this might be out the scope of > Atom, but it does create problems for interoparability. It seems to be in scope for Atom because the <{whatever_xhtml_ns}div> trick is specified by us (ie it's a solution of our own making). cheers Bill From owner-atom-syntax@mail.imc.org Mon Apr 11 16:32:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21977 for ; Mon, 11 Apr 2005 16:32:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BKIUnW072126; Mon, 11 Apr 2005 13:18:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3BKIUUT072125; Mon, 11 Apr 2005 13:18:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3BKITHc072118 for ; Mon, 11 Apr 2005 13:18:29 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-2 ([129.148.9.73]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3BKITXi017416 for ; Mon, 11 Apr 2005 14:18:29 -0600 (MDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IES00B01TJXK0@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Mon, 11 Apr 2005 16:18:29 -0400 (EDT) Received: from localhost (vpn-129-150-35-167.Central.Sun.COM [129.150.35.167]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IES00HSOTQS20@bur-mail1.east.sun.com> for atom-syntax@imc.org; Mon, 11 Apr 2005 16:18:29 -0400 (EDT) Received: from ndw by localhost with local (Exim 4.50) id 1DL5MZ-0003vv-NT for atom-syntax@imc.org; Mon, 11 Apr 2005 16:18:27 -0400 X-URL: http://nwalsh.com/ Date: Mon, 11 Apr 2005 16:18:27 -0400 From: Norman Walsh Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-reply-to: <425AD3EE.5070701@annevankesteren.nl> To: atom-syntax@imc.org Message-id: <87ekdhqd7w.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Anne van Kesteren was heard to say: | Norman Walsh wrote: |> But I hope not. I don't really want to have to rev the Atom format |> spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0 |> stuff in my xhtml:div elements and let the down-stream appliation work |> it out. | | XHTML 2 does have a different namespace. Ouch. I had forgotten or failed to notice that. Sigh. I'm not sure what to do now. I think it would be nice if Atom 1.0 could work with XHTML 1.0 and 2.0. But that means tinkering a bit with the language. | Future versions of XHTML may | or may not have a DIV element. In theory, sure, but in practice? HTML isn't likely to lose the element with the local-name "div" is it, really? | I agree that this might be out the | scope of Atom, but it does create problems for interoparability. Yep. | Also, what do you expect feed readers to support for XHTML versions, etc. I don't have any. I'll tailor my content to suit what the major vendors support, just like I do with my plain old HTML today. In practice, my feeds contain no markup at all (because I'm still generating RSS and I will not produce escaped markup). Be seeing you, norm =2D-=20 Norman Walsh | The effects of weakness are http://nwalsh.com/ | inconceivable, and more prodigious than | those of the most violent | passions.--Cardinal De Retz --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCWtuTOyltUcwYWjsRAjL7AJ9GXxh/GR8CsIAVtgUwPBVg+2E1swCbB358 WOSE+78vuCXi+Y24whmx+lM= =UB4W -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Mon Apr 11 20:19:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15471 for ; Mon, 11 Apr 2005 20:19:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C03cuF002442; Mon, 11 Apr 2005 17:03:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3C03c3k002441; Mon, 11 Apr 2005 17:03:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C03aVU002252 for ; Mon, 11 Apr 2005 17:03:37 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050412000329.YXQW12495.mta10-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com> for ; Tue, 12 Apr 2005 01:03:29 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050412000329.WVVL1352.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com> for ; Tue, 12 Apr 2005 01:03:29 +0100 Date: Tue, 12 Apr 2005 01:03:26 +0100 From: David Powell X-Mailer: The Bat! (v3.0.9.13 Return) Professional X-Priority: 3 (Normal) Message-ID: <0927374.20050412010326@djpowell.net> To: Atom Syntax Subject: What is a media type? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The "type" attribute of atom:content can be a MIME media type: > 4.1.3 The "atom:content" Element [...] > 4.1.3.1 The "type" attribute [...] > [...] Failing that, it MUST be a MIME media type [RFC2045] with a > discrete top-level type (see Section 5 of [RFC2045]). After looking at RFC2045, I wasn't very clear about what a "media type" is. Does it include parameters? Parts of 2045 suggest that a "media type" might include parameters: > 5. Content-Type Header Field > > The purpose of the Content-Type field is to describe the data > contained in the body [...] The value in this field is called a > media type. Other parts (most of the document in fact), suggest that a "media type" is only the top level element, such as "text": > After the media type and subtype names, the remainder of the header > field is simply a set of parameters Is "media type" an accurate term for us to use? I'm asking this because I really don't know whether parameters are supposed to be allowed in the "type" attribute or not. -- Dave From owner-atom-syntax@mail.imc.org Mon Apr 11 22:26:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24184 for ; Mon, 11 Apr 2005 22:26:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C2AJa1019166; Mon, 11 Apr 2005 19:10:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3C2AJH4019165; Mon, 11 Apr 2005 19:10:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C2AHte019147 for ; Mon, 11 Apr 2005 19:10:18 -0700 (PDT) (envelope-from porges@gmail.com) Received: by rproxy.gmail.com with SMTP id b11so1231581rne for ; Mon, 11 Apr 2005 19:10:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=jV23rmYFAkvjrfoOGjYhbTCgji8n1vyenJFOM1FHOSBpPJs9VUOg07SHmctOHhxr3DLLgRL0waa8vjKlr2TFx/ITkHeEUin+nbDcu3ChkRJzaGq3QdByBasgzoig/9EbrcBUffvf5Z924JDKpF5mUbrf41CEaGZNCu2GTynDZRU= Received: by 10.11.122.71 with SMTP id u71mr168167cwc; Mon, 11 Apr 2005 19:10:17 -0700 (PDT) Received: by 10.11.122.44 with HTTP; Mon, 11 Apr 2005 19:10:17 -0700 (PDT) Message-ID: Date: Tue, 12 Apr 2005 14:10:17 +1200 From: Porges Reply-To: Porges To: atom-syntax@imc.org Subject: IRI/URI Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit OK, first-time poster :) I was just thinking about IRIs recently and thought about a possible source of ambiguousness. If the URI element can be EITHER an IRI or a URI, then: http://example.com/200%25equalsZero This is both a valid IRI and a valid URI, but if it is considered to be an IRI it will point to a different location than if it is considered to be a URI. IRI (as URI): http://example.com/200%2525equalsZero URI: http://example.com/200%25equalsZero Reading through the draft, it seems like IRIs might be the only thing allowed. If so, could this be made clearer - through a renaming of the element for instance I'm not sure if this is even a problem, perhaps there's something I've missed in the stack of protocols sitting out there. Feel free to castrate me if this is the case, I've gotten myself rather confused trying to work through this by myself and thought I'd ask some more knowledgeable people ;) From owner-atom-syntax@mail.imc.org Tue Apr 12 01:47:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05915 for ; Tue, 12 Apr 2005 01:47:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C5VN1L044534; Mon, 11 Apr 2005 22:31:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3C5VNH0044533; Mon, 11 Apr 2005 22:31:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C5VLek044508 for ; Mon, 11 Apr 2005 22:31:22 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 29E96A32BD; Tue, 12 Apr 2005 01:31:19 -0400 (EDT) In-Reply-To: <5b29c515110e3fbee7186e18a47661c0@mnot.net> References: <046F43A8D79C794FA4733814869CDF0749C98A@dul1wnexmb01.vcorp.ad.vrsn.com> <5b29c515110e3fbee7186e18a47661c0@mnot.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03ffeb88eaa0ed778ab9f07a04b81aea@mnot.net> Content-Transfer-Encoding: 7bit Cc: Scott Hollenbeck , atom-syntax@imc.org, Tim Bray X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: AD Review Comments and Questions: draft-ietf-atompub-format-07 Date: Mon, 11 Apr 2005 22:31:17 -0700 To: Mark Nottingham X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Oops; I meant draft-freed-media-type-reg. On Apr 6, 2005, at 5:13 PM, Mark Nottingham wrote: > >>> Section 4: RFC 2045 is referenced. 2045 is on its way to being >>> obsoleted by >>> draft-freed-mime-p4 (in the RFC Editor queue) and >>> draft-freed-media-type-reg >>> (in last call). Can the more recent documents be referenced instead >>> of >>> 2045? >> >> Rob/Mark? > > I think all of the references would go to draft-freed-mime-p4. > > As an aside -- it appears we may reference a few documents that are in > the RFC editor queue, or about to be there. It might be good to set > expectations within the WG as to what that means for our publication > schedule. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Apr 12 01:49:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06016 for ; Tue, 12 Apr 2005 01:49:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C5XHAg046101; Mon, 11 Apr 2005 22:33:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3C5XHEk046100; Mon, 11 Apr 2005 22:33:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C5XH1h046084 for ; Mon, 11 Apr 2005 22:33:17 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 862FFA32B9; Tue, 12 Apr 2005 01:33:14 -0400 (EDT) In-Reply-To: <0927374.20050412010326@djpowell.net> References: <0927374.20050412010326@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: What is a media type? Date: Mon, 11 Apr 2005 22:33:12 -0700 To: David Powell X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In my experience, "media type" is colloquially used to mean the type/subtype construct, without parameters; a particular context specifies whether parameters is allowed (e.g., Content-Type). That said, it's not clear in the specs; there is no ABNF rule or even terms that I can find that we could refer to to disambiguate this. We should probably be more precise. As previously mentioned, the updated reference will be to: http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-03.txt I might make a last call comment to the effect that it would be handy to have some to have some terminology disambiguated here. Cheers, On Apr 11, 2005, at 5:03 PM, David Powell wrote: > > > The "type" attribute of atom:content can be a MIME media type: > >> 4.1.3 The "atom:content" Element > [...] >> 4.1.3.1 The "type" attribute > [...] >> [...] Failing that, it MUST be a MIME media type [RFC2045] with a >> discrete top-level type (see Section 5 of [RFC2045]). > > After looking at RFC2045, I wasn't very clear about what a "media > type" is. > > Does it include parameters? Parts of 2045 suggest that a "media type" > might include parameters: > >> 5. Content-Type Header Field >> >> The purpose of the Content-Type field is to describe the data >> contained in the body [...] The value in this field is called a >> media type. > > > Other parts (most of the document in fact), suggest that a "media > type" is only the top level element, such as "text": > >> After the media type and subtype names, the remainder of the header >> field is simply a set of parameters > > > Is "media type" an accurate term for us to use? > > I'm asking this because I really don't know whether parameters are > supposed to be allowed in the "type" attribute or not. > > -- > Dave > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Apr 12 02:49:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01114 for ; Tue, 12 Apr 2005 02:49:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C6XTg3073458; Mon, 11 Apr 2005 23:33:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3C6XTU9073457; Mon, 11 Apr 2005 23:33:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C6XR5s073441 for ; Mon, 11 Apr 2005 23:33:28 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 92749A320D; Tue, 12 Apr 2005 02:33:26 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: IRI/URI Date: Mon, 11 Apr 2005 23:33:21 -0700 To: Porges X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Welcome ;) With the caveat that I'm not an i18n expert; what do you mean by 'different location'? IRIs don't have a separate level of %-encoding on top of that used by URIs; rather, as I understand it, they leverage the URI %-encoding mechanism, by just standardising on UTF-8 for the character set of encoded characters. Thus, there would be no difference between an IRI and a URI containing a '%' as payload, rather than an escape (as you show). There's another underlying issue here, which I think Martin brushed up against at one point in the past. Basically, it's whether there is information in the distinction between something being an IRI vs. it being a URI. Compared bit-for-bit, there is no difference, and there isn't any difference if you dereference them; it's just whether you put any information in the difference. I'm of the opinion that there is no difference; although it's useful to have different terms for them to built conformant systems appropriately, purposely saying that there's a difference between two character-for-character identical identifiers isn't useful, and would be harmful in many cases. Cheers, On Apr 11, 2005, at 7:10 PM, Porges wrote: > > OK, first-time poster :) > > I was just thinking about IRIs recently and thought about a possible > source of ambiguousness. If the URI element can be EITHER an IRI or a > URI, then: > > http://example.com/200%25equalsZero > > This is both a valid IRI and a valid URI, but if it is considered to > be an IRI it will point to a different location than if it is > considered to be a URI. > > IRI (as URI): http://example.com/200%2525equalsZero > URI: http://example.com/200%25equalsZero > > Reading through the draft, it seems like IRIs might be the only thing > allowed. If so, could this be made clearer - through a renaming of the > element for instance > > I'm not sure if this is even a problem, perhaps there's something I've > missed in the stack of protocols sitting out there. Feel free to > castrate me if this is the case, I've gotten myself rather confused > trying to work through this by myself and thought I'd ask some more > knowledgeable people ;) > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Apr 12 03:30:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03285 for ; Tue, 12 Apr 2005 03:30:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C7BiKv089662; Tue, 12 Apr 2005 00:11:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3C7BixP089661; Tue, 12 Apr 2005 00:11:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C7Bgmo089608 for ; Tue, 12 Apr 2005 00:11:43 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j3C7Ba726310; Tue, 12 Apr 2005 16:11:36 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 40d346a6_ab23_11d9_89e8_0030482532aa_26359; Tue, 12 Apr 2005 16:19:48 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO00227B; 12 Apr 05 16:12:45 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 12 Apr 05 16:12:31 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.52) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG00227A; 12 Apr 05 16:12:20 +0900 Message-Id: <6.0.0.20.2.20050412151531.0b3f20d0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 12 Apr 2005 16:09:03 +0900 To: Porges , atom-syntax@imc.org From: Martin Duerst Subject: Re: IRI/URI In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit At 11:10 05/04/12, Porges wrote: > >OK, first-time poster :) > >I was just thinking about IRIs recently and thought about a possible >source of ambiguousness. If the URI element can be EITHER an IRI or a >URI, then: > >http://example.com/200%25equalsZero > >This is both a valid IRI and a valid URI, but if it is considered to >be an IRI it will point to a different location than if it is >considered to be a URI. Sorry, wrong. No need to worry. >IRI (as URI): http://example.com/200%2525equalsZero Wrong. Please check section 3.1 of RFC 3987 again. At the start of Step 2, it says: For each character in 'ucschar' or 'iprivate', apply steps 2.1 through 2.3 below. The "%" character is neither part of 'ucschar' nor of 'iprivate', so it doesn't get escaped when converting from an IRI to an URI. Regards, Martin. >URI: http://example.com/200%25equalsZero > >Reading through the draft, it seems like IRIs might be the only thing >allowed. If so, could this be made clearer - through a renaming of the >element for instance > >I'm not sure if this is even a problem, perhaps there's something I've >missed in the stack of protocols sitting out there. Feel free to >castrate me if this is the case, I've gotten myself rather confused >trying to work through this by myself and thought I'd ask some more >knowledgeable people ;) From owner-atom-syntax@mail.imc.org Tue Apr 12 04:14:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06601 for ; Tue, 12 Apr 2005 04:14:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C7waiq009744; Tue, 12 Apr 2005 00:58:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3C7wZT2009743; Tue, 12 Apr 2005 00:58:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3C7wZeI009732 for ; Tue, 12 Apr 2005 00:58:35 -0700 (PDT) (envelope-from porges@gmail.com) Received: by rproxy.gmail.com with SMTP id b11so1276441rne for ; Tue, 12 Apr 2005 00:58:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=J9KavDmsabASUb7Hum3D5mbuhXjbCABKaWbh89z/Eshjy8wMwP6ETe+2GqrSDGkVobVaekJtIMnD6qhTD+0l85cCUoy7lW3eEaTbaVagFAaeDvNEug3Xp5Exwd2QLBz4+10+Gxa2CvKDY2OU+in7Dl3A8eYoW2Tb1UwWWL+By5U= Received: by 10.11.122.71 with SMTP id u71mr172638cwc; Tue, 12 Apr 2005 00:58:34 -0700 (PDT) Received: by 10.11.122.44 with HTTP; Tue, 12 Apr 2005 00:58:34 -0700 (PDT) Message-ID: Date: Tue, 12 Apr 2005 19:58:34 +1200 From: Porges Reply-To: Porges To: atom-syntax@imc.org Subject: Re: IRI/URI In-Reply-To: <6.0.0.20.2.20050412151531.0b3f20d0@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <6.0.0.20.2.20050412151531.0b3f20d0@itmail.it.aoyama.ac.jp> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3C7wZeI009737 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Thank you for the correction, Martin Dürst. ...I have a bit of a problem reading technical documents, my eyes tend to glaze over a bit... Please don't beat me too hard :) On Apr 12, 2005 7:09 PM, Martin Duerst wrote: > At 11:10 05/04/12, Porges wrote: > >OK, first-time poster :) > > > >I was just thinking about IRIs recently and thought about a possible > >source of ambiguousness. If the URI element can be EITHER an IRI or a > >URI, then: > > > >http://example.com/200%25equalsZero > > > >This is both a valid IRI and a valid URI, but if it is considered to > >be an IRI it will point to a different location than if it is > >considered to be a URI. > > Sorry, wrong. No need to worry. > > >IRI (as URI): http://example.com/200%2525equalsZero > > Wrong. Please check section 3.1 of RFC 3987 again. > > At the start of Step 2, it says: > > For each character in 'ucschar' or 'iprivate', > apply steps 2.1 through 2.3 below. The "%" character > is neither part of 'ucschar' nor of 'iprivate', so > it doesn't get escaped when converting from an IRI > to an URI. > > Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Apr 12 12:58:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15651 for ; Tue, 12 Apr 2005 12:58:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CGeWlG035802; Tue, 12 Apr 2005 09:40:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3CGeWR7035801; Tue, 12 Apr 2005 09:40:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CGeQex035792; Tue, 12 Apr 2005 09:40:27 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6.0.0.20.2.20050412151531.0b3f20d0@itmail.it.aoyama.ac.jp> Date: Tue, 12 Apr 2005 09:40:22 -0700 To: Porges , atom-syntax@imc.org From: Paul Hoffman Subject: Re: IRI/URI Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:58 PM +1200 4/12/05, Porges wrote: >...I have a bit of a problem reading technical documents, my eyes tend >to glaze over a bit... > >Please don't beat me too hard :) Note to everyone who feels the way Porges does: At this point in the process, having implementers who are unfamiliar with all the discussion on this mailing list reading the document is very valuable to us. It is even more valuable for you to ask questions such as Porges has. If 90% of your questions get replies such as "you didn't read it correctly", that leaves 10% of the questions helping us clarify the document before it is finished. That is a Very Good Thing for us, and for the people who will become new implementers in the future when this mailing list is a historical memory. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Apr 12 14:04:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20858 for ; Tue, 12 Apr 2005 14:04:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CHkE7j042685; Tue, 12 Apr 2005 10:46:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3CHkEmP042684; Tue, 12 Apr 2005 10:46:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CHkCCx042667 for ; Tue, 12 Apr 2005 10:46:13 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:59122 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228966AbVDLRqL (ORCPT ); Tue, 12 Apr 2005 20:46:11 +0300 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <87k6n9rub9.fsf@nwalsh.com> References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Date: Tue, 12 Apr 2005 20:45:56 +0300 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 11, 2005, at 22:23, Norman Walsh wrote: > But I hope not. I don't really want to have to rev the Atom format > spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0 > stuff in my xhtml:div elements and let the down-stream appliation work > it out. It will be nice to have the div in the XHTML 1.x namespace and the contents in the XHTML 2.0 namespace. Namespace div indeed. :-) But XHTML 2.0 is a different language form XHTML 1.x. Why do you think XHTML 2.0 fragments should be allowed as type='xhtml'? Just because XHTML 2.0 has "XHTML" in the name? If it is not about the name, why not DocBook NG fragments? One might argue that DocBook NG has a better chance of getting browser support than XHTML 2.0. ;-) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Tue Apr 12 17:37:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14694 for ; Tue, 12 Apr 2005 17:37:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CLKhHX057605; Tue, 12 Apr 2005 14:20:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3CLKhWK057604; Tue, 12 Apr 2005 14:20:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CLKg6I057598 for ; Tue, 12 Apr 2005 14:20:42 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3CLKfi7006094 for ; Tue, 12 Apr 2005 15:20:42 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEU00A6BRAHSB@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 12 Apr 2005 15:20:41 -0600 (MDT) Received: from [10.192.15.188] ([192.18.45.134]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEU00HCURAGJS@mail.sun.net> for atom-syntax@imc.org; Tue, 12 Apr 2005 15:20:41 -0600 (MDT) Date: Tue, 12 Apr 2005 14:21:18 -0700 From: Tim Bray Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-reply-to: <87ekdhqd7w.fsf@nwalsh.com> To: Norman Walsh Cc: atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 11, 2005, at 1:18 PM, Norman Walsh wrote: > Sigh. I'm not sure what to do now. I think it would be nice if Atom 1.0 > could work with XHTML 1.0 and 2.0. But that means tinkering a bit with > the language. We need to do a bit of cleanup. But bear in mind that the measuring stick is interoperability. In the case of type="html", the language is well-taken (from 3.1.1.1): If the value of "type" is "html", the content of the Text construct MUST NOT contain child elements, and SHOULD be suitable for handling as HTML "suitable for handling as HTML" may be a bit hand-wavy but corresponds exactly to reality and is about as far as we can realistically go. For XHTML on the other hand: If the value of "type" is "xhtml", the content of the Text construct MUST be a single XHTML div element [W3C.REC-xhtml-basic-20001219]. The XHTML div MUST contain XHTML text and markup that could validly appear within an XHTML div element. First, the word "validly" has to go. There is little (any?) interoperability benefit, but immense costs, in requiring XHTML validation. I suggest rewording to make this congruent with the HTML language If the value of "type" is "xhtml". the content of the Text construct MUST be a single XHTML div element. The XHTML div must contain XHTML 1.0 [XHTML traditional reference] text and markup that SHOULD be suitable for handling as XHTML 1.0 Traditional. I recommend we use Transitional, since I don't think we should get into micro-managing the purity of the payload; but clearly Frameset would be going too far. -Tim From owner-atom-syntax@mail.imc.org Tue Apr 12 18:17:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18320 for ; Tue, 12 Apr 2005 18:17:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CM2t7U059677; Tue, 12 Apr 2005 15:02:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3CM2tT4059676; Tue, 12 Apr 2005 15:02:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CM2rM0059638 for ; Tue, 12 Apr 2005 15:02:54 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.3]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DLTT4-0005bx-Mq; Tue, 12 Apr 2005 22:02:46 +0000 Message-ID: <425C4588.2010302@franklinmint.fm> Date: Tue, 12 Apr 2005 18:02:48 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Norman Walsh , atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > We need to do a bit of cleanup. But bear in mind that the measuring > stick is interoperability. In the case of type="html", the language is > well-taken (from 3.1.1.1): > > If the value of "type" is "html", the content of the Text construct > MUST NOT contain child elements, and SHOULD be suitable for handling > as HTML > > "suitable for handling as HTML" may be a bit hand-wavy but corresponds > exactly to reality and is about as far as we can realistically go. How about this text for XHTML: If the value of "type" is "xhtml", the content of the Text construct MUST be a single XHTML div element [XHTML transitional reference], and SHOULD be suitable for handling as XHTML. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 12 19:51:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25929 for ; Tue, 12 Apr 2005 19:51:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CNPWBI065031; Tue, 12 Apr 2005 16:25:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3CNPW1A065030; Tue, 12 Apr 2005 16:25:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3CNPVCn065024 for ; Tue, 12 Apr 2005 16:25:31 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3CNPUi7004571 for ; Tue, 12 Apr 2005 17:25:31 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IEU00EKTX2INV@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 12 Apr 2005 17:25:30 -0600 (MDT) Received: from [10.192.15.188] ([192.18.45.134]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IEU00H9MX2HJS@mail.sun.net> for atom-syntax@imc.org; Tue, 12 Apr 2005 17:25:30 -0600 (MDT) Date: Tue, 12 Apr 2005 16:26:08 -0700 From: Tim Bray Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-reply-to: <425C4588.2010302@franklinmint.fm> To: Robert Sayre Cc: atom-syntax@imc.org, Norman Walsh Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425C4588.2010302@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 12, 2005, at 3:02 PM, Robert Sayre wrote: > How about this text for XHTML: > > If the value of "type" is "xhtml", the content of the Text construct > MUST be a single XHTML div element [XHTML transitional reference], and > SHOULD be suitable for handling as XHTML. +1 --Tim From owner-atom-syntax@mail.imc.org Tue Apr 12 20:32:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29163 for ; Tue, 12 Apr 2005 20:32:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3D0Fmc3067874; Tue, 12 Apr 2005 17:15:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3D0FmVv067873; Tue, 12 Apr 2005 17:15:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3D0FmcB067863 for ; Tue, 12 Apr 2005 17:15:48 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEU00IU3Z4SZU40@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Wed, 13 Apr 2005 02:10:04 +0200 (CEST) Received: from quark ([80.203.88.140]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEU00KPTZG9Q6M0@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Wed, 13 Apr 2005 02:16:58 +0200 (CEST) Date: Wed, 13 Apr 2005 02:18:29 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-reply-to: <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> To: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425C4588.2010302@franklinmint.fm> User-Agent: Opera M2(BETA2)/8.0 (Win32, build 7483) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Wed, 13 Apr 2005 00:02:48 +0200, Robert Sayre wrote: > How about this text for XHTML: > > If the value of "type" is "xhtml", the content of the Text construct > MUST be a single XHTML div element [XHTML transitional reference], and > SHOULD be suitable for handling as XHTML. Good, but I would like us to have the same recommendations in the Atom specification as W3C, namely to use a Strict DOCTYPE. How to word this is still a bit blurred to me. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Tue Apr 12 20:35:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29561 for ; Tue, 12 Apr 2005 20:35:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3D0MOlK068363; Tue, 12 Apr 2005 17:22:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3D0MODZ068362; Tue, 12 Apr 2005 17:22:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3D0MNrc068355 for ; Tue, 12 Apr 2005 17:22:24 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEU00IWRZFGZU40@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Wed, 13 Apr 2005 02:16:28 +0200 (CEST) Received: from quark ([80.203.88.140]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEU00LL0ZQYS6F0@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Wed, 13 Apr 2005 02:23:23 +0200 (CEST) Date: Wed, 13 Apr 2005 02:24:55 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-reply-to: To: Henri Sivonen Cc: Atom Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <42579382.3040003@gmx.de> <87k6n9rub9.fsf@nwalsh.com> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> User-Agent: Opera M2(BETA2)/8.0 (Win32, build 7483) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Tue, 12 Apr 2005 19:45:56 +0200, Henri Sivonen wrote: > But XHTML 2.0 is a different language form XHTML 1.x. Why do you think > XHTML 2.0 fragments should be allowed as type='xhtml'? Just because > XHTML 2.0 has "XHTML" in the name? Yes. > If it is not about the name, why not DocBook NG fragments? Because "DocBook" does not have "XHTML" in its name, and will not under any circumstance cause confusion with Atom using the term "XHTML" as a type for content. Since XHTML 1.0 and 2.0 and most likely 2.1, 3.0 and whatnot will bear the names "XHTML", we should allow all of them to be used in Atom. Or, we should restrict the allowed XHTML versions in the specification to just include 1.x. That leads to different problems, though, since people would then think they could use XHTML 1.0 Frameset or XHTML 1.1, which are totally different from one another, and will hurt interoperability a great deal. I'd say that we should limit the allowed XHTML versions (including both version number and DOCTYPEs) to be used in Atom to XHTML 1.0 Transitional, XHTML 1.0 Strict and XHTML 1.1. Since XHTML 2.0 isn't finished yet, it is a bit problematic including language about it in the Atom specification, so I think we should leave it out at least until it is done. Then we can "patch" Atom somehow with an I-D or whatever to include language about XHTML 2.0. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Apr 13 02:22:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16335 for ; Wed, 13 Apr 2005 02:22:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3D67Gmx013146; Tue, 12 Apr 2005 23:07:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3D67GLB013145; Tue, 12 Apr 2005 23:07:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3D67Fct013127 for ; Tue, 12 Apr 2005 23:07:16 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:59699 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228826AbVDMGHN (ORCPT ); Wed, 13 Apr 2005 09:07:13 +0300 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <425C4588.2010302@franklinmint.fm> References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425C4588.2010302@franklinmint.fm> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <79fded4a34b44665ce4f0ca73f900f12@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Date: Wed, 13 Apr 2005 09:06:59 +0300 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 13, 2005, at 01:02, Robert Sayre wrote: > How about this text for XHTML: > > If the value of "type" is "xhtml", the content of the Text construct > MUST be a single XHTML div element [XHTML transitional reference], and > SHOULD be suitable for handling as XHTML. Instead of saying "XHTML" it would be clearer to say "XHTML 1.x" or defining it in terms of the XHTML 1.x namespace URI. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed Apr 13 02:23:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18623 for ; Wed, 13 Apr 2005 02:23:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3D68kAl013674; Tue, 12 Apr 2005 23:08:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3D68k7s013673; Tue, 12 Apr 2005 23:08:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3D67Fcv013127 for ; Tue, 12 Apr 2005 23:08:45 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:59713 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228787AbVDMGIp convert rfc822-to-8bit (ORCPT ); Wed, 13 Apr 2005 09:08:45 +0300 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425C4588.2010302@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2f51d7d3708a263570d3a81833f7fb25@iki.fi> Content-Transfer-Encoding: 8BIT From: Henri Sivonen Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Date: Wed, 13 Apr 2005 09:08:42 +0300 To: Atom-Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Apr 13, 2005, at 03:18, Asbjørn Ulsberg wrote: > namely to use a Strict DOCTYPE. type='xhtml' takes a fragment and Atom is DTDless. Better to stay away from the word DOCTYPE. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed Apr 13 08:48:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22227 for ; Wed, 13 Apr 2005 08:48:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DCYeCV049498; Wed, 13 Apr 2005 05:34:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DCYekG049497; Wed, 13 Apr 2005 05:34:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3DCYc8u049447 for ; Wed, 13 Apr 2005 05:34:39 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 13 Apr 2005 12:34:32 -0000 Received: from xdsl-81-173-175-245.netcologne.de (EHLO klangraum) [81.173.175.245] by mail.gmx.net (mp011) with SMTP; 13 Apr 2005 14:34:32 +0200 X-Authenticated: #163624 Date: Wed, 13 Apr 2005 14:37:12 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Message-ID: <20050413123712.GA31026@klangraum> Mail-Followup-To: Atom Syntax References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425C4588.2010302@franklinmint.fm> <79fded4a34b44665ce4f0ca73f900f12@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79fded4a34b44665ce4f0ca73f900f12@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: * Henri Sivonen [2005-04-13 08:25]: > On Apr 13, 2005, at 01:02, Robert Sayre wrote: > > [XHTML transitional reference] > > Instead of saying "XHTML" it would be clearer to say "XHTML > 1.x" or defining it in terms of the XHTML 1.x namespace URI. He already did, no? Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Wed Apr 13 08:48:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22284 for ; Wed, 13 Apr 2005 08:48:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DCbF63050484; Wed, 13 Apr 2005 05:37:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DCbF7T050483; Wed, 13 Apr 2005 05:37:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3DCbD2W050437 for ; Wed, 13 Apr 2005 05:37:14 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 13 Apr 2005 12:37:07 -0000 Received: from xdsl-81-173-175-245.netcologne.de (EHLO klangraum) [81.173.175.245] by mail.gmx.net (mp007) with SMTP; 13 Apr 2005 14:37:07 +0200 X-Authenticated: #163624 Date: Wed, 13 Apr 2005 14:39:48 +0200 From: "A. Pagaltzis" To: Atom Syntax Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Message-ID: <20050413123948.GB31026@klangraum> Mail-Followup-To: Atom Syntax References: <42579382.3040003@gmx.de> <87k6n9rub9.fsf@nwalsh.com> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Asbjørn Ulsberg [2005-04-13 02:35]: > Or, we should restrict the allowed XHTML versions in the > specification to just include 1.x. That leads to different > problems, though, since people would then think they could use > XHTML 1.0 Frameset or XHTML 1.1, which are totally different > from one another, and will hurt interoperability a great deal. Multiple proposals already posted for the wording of this section suggestion a refererence to the XHTML 1.0 Transitional spec. That would seem to have preempted this problem. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Wed Apr 13 09:29:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24823 for ; Wed, 13 Apr 2005 09:29:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DDBs7S053894; Wed, 13 Apr 2005 06:11:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DDBsn3053893; Wed, 13 Apr 2005 06:11:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3DDBqpQ053883 for ; Wed, 13 Apr 2005 06:11:53 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 13 Apr 2005 13:11:46 -0000 Received: from dsl-084-056-228-197.arcor-ip.net (EHLO localhost) [84.56.228.197] by mail.gmx.net (mp025) with SMTP; 13 Apr 2005 15:11:46 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: David Powell Cc: Atom Syntax Subject: Re: What is a media type? Date: Wed, 13 Apr 2005 15:12:14 +0200 Message-ID: <42681a7c.364290140@smtp.bjoern.hoehrmann.de> References: <0927374.20050412010326@djpowell.net> In-Reply-To: <0927374.20050412010326@djpowell.net> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * David Powell wrote: >I'm asking this because I really don't know whether parameters are >supposed to be allowed in the "type" attribute or not. http://www.imc.org/atom-syntax/mail-archive/msg08283.html -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From owner-atom-syntax@mail.imc.org Wed Apr 13 11:02:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03623 for ; Wed, 13 Apr 2005 11:02:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DEm1Wh061947; Wed, 13 Apr 2005 07:48:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DEm1aH061946; Wed, 13 Apr 2005 07:48:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DEm0qN061929 for ; Wed, 13 Apr 2005 07:48:00 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id BC1D2424 for ; Wed, 13 Apr 2005 07:47:53 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j3DEljng000447 for ; Wed, 13 Apr 2005 07:47:51 -0700 (PDT) Date: Wed, 13 Apr 2005 07:47:52 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Message-ID: In-Reply-To: <79fded4a34b44665ce4f0ca73f900f12@iki.fi> References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425C4588.2010302@franklinmint.fm> <79fded4a34b44665ce4f0ca73f900f12@iki.fi> X-Mailer: Mulberry/4.0.0a7 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On April 13, 2005 9:06:59 AM +0300 Henri Sivonen wrote: > > Instead of saying "XHTML" it would be clearer to say "XHTML 1.x" or defining it > in terms of the XHTML 1.x namespace URI. This could work. "XHTML 1.0" will not be confused with a media type. When XHTML 2.0 is ready, we can add a supplemental RFC which defines a new attribute value for that. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Wed Apr 13 14:12:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19111 for ; Wed, 13 Apr 2005 14:12:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DHq1gm079205; Wed, 13 Apr 2005 10:52:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DHq1dk079204; Wed, 13 Apr 2005 10:52:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DHq0mn079192 for ; Wed, 13 Apr 2005 10:52:00 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:60484 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228765AbVDMRv6 (ORCPT ); Wed, 13 Apr 2005 20:51:58 +0300 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <20050413123712.GA31026@klangraum> References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425C4588.2010302@franklinmint.fm> <79fded4a34b44665ce4f0ca73f900f12@iki.fi> <20050413123712.GA31026@klangraum> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Date: Wed, 13 Apr 2005 20:51:46 +0300 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 13, 2005, at 15:37, A. Pagaltzis wrote: > * Henri Sivonen [2005-04-13 08:25]: >> On Apr 13, 2005, at 01:02, Robert Sayre wrote: >>> [XHTML transitional reference] >> >> Instead of saying "XHTML" it would be clearer to say "XHTML >> 1.x" or defining it in terms of the XHTML 1.x namespace URI. > > He already did, no? Not as clearly as possible. If 1.x is meant, it should be clearly pointed out. If 1.0 (not Ruby nor the What WG stuff) is meant, it should be clearly pointed out. I prefer 1.x over 1.0 or 2.0. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed Apr 13 14:24:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19945 for ; Wed, 13 Apr 2005 14:24:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DI69wd079984; Wed, 13 Apr 2005 11:06:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DI69MP079983; Wed, 13 Apr 2005 11:06:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DI67HC079965 for ; Wed, 13 Apr 2005 11:06:08 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 11215 invoked by uid 10); 13 Apr 2005 18:06:01 -0000 Received: (vexira-qq 11200-EB7FC62 invoked from network) 13 Apr 2005 20:06:01 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 13 Apr 2005 18:06:01 -0000 Message-ID: <425D5F91.9040809@annevankesteren.nl> Date: Wed, 13 Apr 2005 20:06:09 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Walsh CC: atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> In-Reply-To: <87ekdhqd7w.fsf@nwalsh.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > / Anne van Kesteren was heard to say: > | Norman Walsh wrote: > |> But I hope not. I don't really want to have to rev the Atom format > |> spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0 > |> stuff in my xhtml:div elements and let the down-stream appliation work > |> it out. > | > | XHTML 2 does have a different namespace. > > Ouch. I had forgotten or failed to notice that. Yeah, using namespaces for versioning sucks... > | Future versions of XHTML may > | or may not have a DIV element. > > In theory, sure, but in practice? HTML isn't likely to lose the > element with the local-name "div" is it, really? Ask Ian Hickson. I believe he is planning to drop it in the WHATWG version of XHTML. > | Also, what do you expect feed readers to support for XHTML versions, etc. > > I don't have any. I'll tailor my content to suit what the major > vendors support, just like I do with my plain old HTML today. In > practice, my feeds contain no markup at all (because I'm still > generating RSS and I will not produce escaped markup). I don't really like this point of view. This is exactly what creates interoperability problems and people will blame Atom in the end for promising to solve problems it does not. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Wed Apr 13 15:47:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27290 for ; Wed, 13 Apr 2005 15:47:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DJWNuJ085177; Wed, 13 Apr 2005 12:32:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DJWNw7085176; Wed, 13 Apr 2005 12:32:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DJWMXJ085169 for ; Wed, 13 Apr 2005 12:32:23 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.3]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DLnaz-0006Z7-Cy; Wed, 13 Apr 2005 19:32:17 +0000 Message-ID: <425D73C0.8080601@franklinmint.fm> Date: Wed, 13 Apr 2005 15:32:16 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren CC: Norman Walsh , atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425D5F91.9040809@annevankesteren.nl> In-Reply-To: <425D5F91.9040809@annevankesteren.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > I don't really like this point of view. This is exactly what creates > interoperability problems and people will blame Atom in the end for > promising to solve problems it does not. Atom promised to solve HTML interop issues? Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 13 15:48:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27376 for ; Wed, 13 Apr 2005 15:48:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DJVCFZ085124; Wed, 13 Apr 2005 12:31:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DJVCcH085123; Wed, 13 Apr 2005 12:31:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DJV8Uc085110 for ; Wed, 13 Apr 2005 12:31:08 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050413193101.GIUJ5539.mta08-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com>; Wed, 13 Apr 2005 20:31:01 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050413193101.QNQI1187.aamta01-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com>; Wed, 13 Apr 2005 20:31:01 +0100 Date: Wed, 13 Apr 2005 20:31:00 +0100 From: David Powell X-Mailer: The Bat! (v3.0.9.13 Return) Professional X-Priority: 3 (Normal) Message-ID: <914154561.20050413203100@djpowell.net> To: Anne van Kesteren CC: Norman Walsh , atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-Reply-To: <425D5F91.9040809@annevankesteren.nl> References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425D5F91.9040809@annevankesteren.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Wednesday, April 13, 2005, 7:06:09 PM, Anne van Kesteren wrote: >> | Also, what do you expect feed readers to support for XHTML versions, etc. >> >> I don't have any. I'll tailor my content to suit what the major >> vendors support, just like I do with my plain old HTML today. In >> practice, my feeds contain no markup at all (because I'm still >> generating RSS and I will not produce escaped markup). > I don't really like this point of view. This is exactly what creates > interoperability problems and people will blame Atom in the end for > promising to solve problems it does not. I agree that the Atom RFC shouldn't be a moving target. How about if we: Make an IANA registry of Atom Text Types, requiring some level of RFC to create new ones. Put text, html, and xhtml in the registry, and specify that xhtml means XHTML1.0 Describe what processors should do if they encounter an Atom Text Type that they don't understand. -- Dave From owner-atom-syntax@mail.imc.org Wed Apr 13 16:57:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06802 for ; Wed, 13 Apr 2005 16:57:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DKj8gB090940; Wed, 13 Apr 2005 13:45:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DKj8jG090939; Wed, 13 Apr 2005 13:45:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3DKj6Rm090896 for ; Wed, 13 Apr 2005 13:45:07 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 13 Apr 2005 20:45:00 -0000 Received: from xdsl-213-196-248-173.netcologne.de (EHLO klangraum) [213.196.248.173] by mail.gmx.net (mp027) with SMTP; 13 Apr 2005 22:45:00 +0200 X-Authenticated: #163624 Date: Wed, 13 Apr 2005 22:47:48 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Message-ID: <20050413204748.GB1959@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425D5F91.9040809@annevankesteren.nl> <914154561.20050413203100@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <914154561.20050413203100@djpowell.net> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * David Powell [2005-04-13 21:50]: > I agree that the Atom RFC shouldn't be a moving target. How > about if we: > > Make an IANA registry of Atom Text Types, requiring some > level of RFC to create new ones. > > Put text, html, and xhtml in the registry, and specify that > xhtml means XHTML1.0 > > Describe what processors should do if they encounter an Atom > Text Type that they don't understand. This is what I first thought, too. Obviously, the last point of these points would be the most important, and extra care would have to be taken not to foul it up. But is this really a good idea? One aspect I don’t like about this proposal is that it swaps a fairly important part of Atom out of the core spec and into a registry, which makes it harder for first-time implementors to pull together all the pieces required. Another aspect is that it seems that it would hurt interop: even if I know which version of the Atom spec is used by an upstream producer or expected by a downstream consumer, I can’t know whether we agree on text types. If support for a set of text types is inextricably tied to support for a certain version of the Atom spec, then no ambiguities arise. A final aspect is that because this is so central to Atom, I don’t know if it can be guaranteed that updates to the spec will not require updates in the registry or vice versa. Should that ever happen, registrations will suddenly have to track which Atom spec version they are for, or contain multiple definitions to be chosen from according to Atom version, or some other mechanism, any form of which will tie registrations and core spec versions to each other. That negates any gain ever had by separating the text types out of the core spec. All in all, I think creating registries is best avoided. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Wed Apr 13 17:26:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08546 for ; Wed, 13 Apr 2005 17:26:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLAshW095243; Wed, 13 Apr 2005 14:10:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DLAsO4095242; Wed, 13 Apr 2005 14:10:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLAqbq095229 for ; Wed, 13 Apr 2005 14:10:53 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3DL9vcv014342; Wed, 13 Apr 2005 22:10:08 +0100 (BST) In-Reply-To: <914154561.20050413203100@djpowell.net> References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425D5F91.9040809@annevankesteren.nl> <914154561.20050413203100@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <290afee358fc9e9dba150051da2be680@mac.com> Content-Transfer-Encoding: 7bit Cc: "Atom-Syntax Syntax'" From: Graham Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Date: Wed, 13 Apr 2005 22:10:04 +0100 To: David Powell X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 13 Apr 2005, at 8:31 pm, David Powell wrote: > I agree that the Atom RFC shouldn't be a moving target. How about if > we: > > Make an IANA registry of Atom Text Types, requiring some level of > RFC to create new ones. > > Put text, html, and xhtml in the registry, and specify that xhtml > means XHTML1.0 > > Describe what processors should do if they encounter an Atom Text > Type that they don't understand. -1 I think introducing new core data types negates the point of having core, well-known data types. XHTML 2.0 is an issue we can solve now. I think it will be safe to leave any further formats to a new rev of the spec, since whatever new thing needs to be added would have to have reached similar popularity to either plain text or HTML. Graham From owner-atom-syntax@mail.imc.org Wed Apr 13 17:44:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09527 for ; Wed, 13 Apr 2005 17:44:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLWqcE096689; Wed, 13 Apr 2005 14:32:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DLWqsq096688; Wed, 13 Apr 2005 14:32:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLWpAv096680 for ; Wed, 13 Apr 2005 14:32:51 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEW00KXFM97Z170@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Wed, 13 Apr 2005 23:27:07 +0200 (CEST) Received: from quark ([80.203.88.140]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEW001VIMKO4N00@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Wed, 13 Apr 2005 23:34:01 +0200 (CEST) Date: Wed, 13 Apr 2005 23:35:35 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-reply-to: To: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <42579382.3040003@gmx.de> <87k6n9rub9.fsf@nwalsh.com> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <20050413123948.GB31026@klangraum> User-Agent: Opera M2(BETA2)/8.0 (Win32, build 7483) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Wed, 13 Apr 2005 14:39:48 +0200, A. Pagaltzis wrote: > Multiple proposals already posted for the wording of this > section suggestion a refererence to the XHTML 1.0 Transitional > spec. That would seem to have preempted this problem. Do we really want to exclude XHTML 1.1 as allowed content in Atom documents? -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Apr 13 17:45:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09614 for ; Wed, 13 Apr 2005 17:45:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLVtTZ096637; Wed, 13 Apr 2005 14:31:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DLVtrv096636; Wed, 13 Apr 2005 14:31:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLVsAJ096614 for ; Wed, 13 Apr 2005 14:31:54 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEW00KY2M7MZ070@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Wed, 13 Apr 2005 23:26:10 +0200 (CEST) Received: from quark ([80.203.88.140]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEW001KFMJ34K00@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Wed, 13 Apr 2005 23:33:03 +0200 (CEST) Date: Wed, 13 Apr 2005 23:34:38 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-reply-to: <2f51d7d3708a263570d3a81833f7fb25@iki.fi> To: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <42579382.3040003@gmx.de> <2f51d7d3708a263570d3a81833f7fb25@iki.fi> <425C4588.2010302@franklinmint.fm> <87ekdhqd7w.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87k6n9rub9.fsf@nwalsh.com> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> User-Agent: Opera M2(BETA2)/8.0 (Win32, build 7483) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Wed, 13 Apr 2005 08:08:42 +0200, Henri Sivonen wrote: >> namely to use a Strict DOCTYPE. > > type='xhtml' takes a fragment and Atom is DTDless. Better to stay away > from the word DOCTYPE. Of course. Still, the allowed elements and attribtues inside the
of Atom Content constructs is bound to the version of XHTML we choose. And the way to identify which version of XHTML you use happens to be done with a DOCTYPE and appurtenant DTD (and sadly not an XSD or similar), so I'm using it only as a way to identify which versions we are to use, not because I want the actual DOCTYPE construct to be allowed within an Atom document. And please note that I have not suggested any form of wording for this specification text yet, so this can be formulated however the group finds best. I have no proposals for specification text at the moment. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Apr 13 18:00:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10270 for ; Wed, 13 Apr 2005 18:00:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLk1El097673; Wed, 13 Apr 2005 14:46:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DLk1Ff097672; Wed, 13 Apr 2005 14:46:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLk0pP097664 for ; Wed, 13 Apr 2005 14:46:00 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:60728 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228754AbVDMVp6 (ORCPT ); Thu, 14 Apr 2005 00:45:58 +0300 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <290afee358fc9e9dba150051da2be680@mac.com> References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425D5F91.9040809@annevankesteren.nl> <914154561.20050413203100@djpowell.net> <290afee358fc9e9dba150051da2be680@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Date: Thu, 14 Apr 2005 00:45:52 +0300 To: "Atom-Syntax Syntax'" X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 14, 2005, at 00:10, Graham wrote: > On 13 Apr 2005, at 8:31 pm, David Powell wrote: > >> I agree that the Atom RFC shouldn't be a moving target. How about if >> we: >> >> Make an IANA registry of Atom Text Types, requiring some level of >> RFC to create new ones. >> >> Put text, html, and xhtml in the registry, and specify that xhtml >> means XHTML1.0 >> >> Describe what processors should do if they encounter an Atom Text >> Type that they don't understand. > > -1 -1 from me as well. Overkill. > I think it will be safe to leave any further formats to a new rev of > the spec, since whatever new thing needs to be added would have to > have reached similar popularity to either plain text or HTML. That pretty much rules out XHTML 2.0, doesn't it? Good ideas from the XHTML 2.0 namespace are being backported to the XHTML 1.x namespace, so it is unlikely for XHTML 2.0 to reach large-scale popularity. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed Apr 13 18:00:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10378 for ; Wed, 13 Apr 2005 18:00:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLgo8R097478; Wed, 13 Apr 2005 14:42:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DLgoIt097477; Wed, 13 Apr 2005 14:42:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DLgn0T097471 for ; Wed, 13 Apr 2005 14:42:50 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DLpdF-0000Bc-NV; Wed, 13 Apr 2005 21:42:45 +0000 Message-ID: <425D9245.6090203@franklinmint.fm> Date: Wed, 13 Apr 2005 17:42:29 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: <42579382.3040003@gmx.de> <2f51d7d3708a263570d3a81833f7fb25@iki.fi> <425C4588.2010302@franklinmint.fm> <87ekdhqd7w.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87k6n9rub9.fsf@nwalsh.com> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Wed, 13 Apr 2005 08:08:42 +0200, Henri Sivonen wrote: > >>> namely to use a Strict DOCTYPE. >> >> >> type='xhtml' takes a fragment and Atom is DTDless. Better to stay >> away from the word DOCTYPE. > > > Of course. Still, the allowed elements and attribtues inside the
> of Atom Content constructs is bound to the version of XHTML we choose. Real world example:
Dell delivered my replacement 2405FPW today. The white line pixel problem had actually disappeared on my first monitor when I switched it on the second day, but when a problem has shown itself once, who is to say it would not come back. I feel better knowing I have a new monitor with zero problems from the start.

So, now all the problems are over, how is the 2405FPW? Outstanding!!!

 What do we have to say about this? Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 13 18:33:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14374 for ; Wed, 13 Apr 2005 18:33:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DMJjIn000395; Wed, 13 Apr 2005 15:19:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3DMJjHg000394; Wed, 13 Apr 2005 15:19:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [165.227.249.220] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3DMJhCV000386 for ; Wed, 13 Apr 2005 15:19:44 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <290afee358fc9e9dba150051da2be680@mac.com> References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425D5F91.9040809@annevankesteren.nl> <914154561.20050413203100@djpowell.net> <290afee358fc9e9dba150051da2be680@mac.com> Date: Wed, 13 Apr 2005 15:19:40 -0700 To: "Atom-Syntax Syntax'" From: Paul Hoffman Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [[ wearing my IETF weenie hat, not my co-chair hat ]] At 10:10 PM +0100 4/13/05, Graham wrote: >-1 > >I think introducing new core data types negates the point of having >core, well-known data types. XHTML 2.0 is an issue we can solve now. > >I think it will be safe to leave any further formats to a new rev of >the spec, since whatever new thing needs to be added would have to >have reached similar popularity to either plain text or HTML. Fully agree with Graham. IANA registries are mostly for things that not core to actually running a spec, and the type of content seems quite core. The "should this be relegated to an IANA registry or not" question come up in almost every IETF WG because it is a question of what is and is not core for a developer. If a protocol has a reason to have lots of registries (such as IPsec, which has a dozen different types of transforms), then it is safer to put more core-ish things in a registry. But if it has only a few, then we should assume that most developers won't bother to look in the IANA registries, greatly reducing interoperability for things that appear only in a registry. I'm fairly certain the Atom format is in the second category. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Apr 13 23:01:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03180 for ; Wed, 13 Apr 2005 23:01:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E2lwZN024887; Wed, 13 Apr 2005 19:47:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3E2lvT2024886; Wed, 13 Apr 2005 19:47:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E2lu5L024875 for ; Wed, 13 Apr 2005 19:47:57 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEX00L5O0U75220@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Thu, 14 Apr 2005 04:42:07 +0200 (CEST) Received: from quark ([80.203.88.140]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEX002WZ15ODAD0@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Thu, 14 Apr 2005 04:49:00 +0200 (CEST) Date: Thu, 14 Apr 2005 04:50:35 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-reply-to: <2f51d7d3708a263570d3a81833f7fb25@iki.fi> To: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <42579382.3040003@gmx.de> <2f51d7d3708a263570d3a81833f7fb25@iki.fi> <425C4588.2010302@franklinmint.fm> <87ekdhqd7w.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87k6n9rub9.fsf@nwalsh.com> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <425D9245.6090203@franklinmint.fm> User-Agent: Opera M2(BETA2)/8.0 (Win32, build 7483) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Wed, 13 Apr 2005 23:42:29 +0200, Robert Sayre wrote: > Real world example: > > [snip example] > > What do we have to say about this? As far as I can see, the code is valid XHTML 1.0 Strict (and thus also both Transitional, Frameset and XHTML 1.1), so I'm not sure what point you're making, Robert. Sure, the code is far from pretty, but the validity of it is okay. We can't demand validation or validity in any way, but we can and should encourage people to follow W3C's recommendations. And for a long time, they have been to code against the strictest DTD possible for the version of (X)HTML you are using. Transitional is a DTD to code against if you're transitioning from invalid DOCTYPE-less HTML or HTML 3.2 to valid HTML 4.01 Strict. XHTML 1.0 Transitional is a mistake, but that discussion is off topic, so I'll leave that for now. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Wed Apr 13 23:50:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06054 for ; Wed, 13 Apr 2005 23:50:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E3blaR029944; Wed, 13 Apr 2005 20:37:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3E3blsg029943; Wed, 13 Apr 2005 20:37:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E3bkQM029937 for ; Wed, 13 Apr 2005 20:37:46 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12ld2tn.cable.mindspring.com ([69.86.139.183] helo=[192.168.1.100]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DLvAm-0008Pq-Gv; Thu, 14 Apr 2005 03:37:44 +0000 Message-ID: <425DE586.3030009@franklinmint.fm> Date: Wed, 13 Apr 2005 23:37:42 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: <42579382.3040003@gmx.de> <2f51d7d3708a263570d3a81833f7fb25@iki.fi> <425C4588.2010302@franklinmint.fm> <87ekdhqd7w.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87k6n9rub9.fsf@nwalsh.com> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <425D9245.6090203@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Asbjørn Ulsberg wrote: > > On Wed, 13 Apr 2005 23:42:29 +0200, Robert Sayre > wrote: > >> Real world example: >> >> [snip example] >> >> What do we have to say about this? > > > As far as I can see, the code is valid XHTML 1.0 Strict (and thus also > both Transitional, Frameset and XHTML 1.1), so I'm not sure what point > you're making, Robert. Sure, the code is far from pretty, but the > validity of it is okay. Thank you, Asbjørn: this is a delightful little problem. You see, XHTML validity is specified in terms of DTDs. Near as I can tell, that example and some of the XHTML examples in the spec are 'invalid' because the local names don't match the DTD, and there are stray xmlns declarations. If any of the current versions of XHTML allow that, we should probably point to that one, but I don't know if any of them do. Here's an example of what I mean: What in the hay are we supposed to reference? Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 14 00:36:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08972 for ; Thu, 14 Apr 2005 00:36:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E4KjWf033364; Wed, 13 Apr 2005 21:20:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3E4KjN9033363; Wed, 13 Apr 2005 21:20:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E4KivY033346 for ; Wed, 13 Apr 2005 21:20:45 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEX00L155505B30@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Thu, 14 Apr 2005 06:15:00 +0200 (CEST) Received: from quark ([80.203.88.140]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEX002ZI5GHIO50@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Thu, 14 Apr 2005 06:21:53 +0200 (CEST) Date: Thu, 14 Apr 2005 06:23:29 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-reply-to: <2f51d7d3708a263570d3a81833f7fb25@iki.fi> To: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <42579382.3040003@gmx.de> <2f51d7d3708a263570d3a81833f7fb25@iki.fi> <425C4588.2010302@franklinmint.fm> <87ekdhqd7w.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87k6n9rub9.fsf@nwalsh.com> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <425D9245.6090203@franklinmint.fm> <425DE586.3030009@franklinmint.fm> User-Agent: Opera M2(BETA2)/8.0 (Win32, build 7483) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Thu, 14 Apr 2005 05:37:42 +0200, Robert Sayre wrote: > Thank you, Asbjørn: this is a delightful little problem. You see, XHTML > validity is specified in terms of DTDs. Near as I can tell, that example > and some of the XHTML examples in the spec are 'invalid' because the > local names don't match the DTD, and there are stray xmlns declarations. > If any of the current versions of XHTML allow that, we should probably > point to that one, but I don't know if any of them do. Ah, nice catch. Didn't even think about it, but you're right: Well-formed XML is not necessarily valid XHTML. > What in the hay are we supposed to reference? That's a very good question I really wished I had an answer to. But right now, I don't. :-\ -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Apr 14 03:22:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10274 for ; Thu, 14 Apr 2005 03:22:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E77c1b094949; Thu, 14 Apr 2005 00:07:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3E77cPK094948; Thu, 14 Apr 2005 00:07:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3E77ZF7094927 for ; Thu, 14 Apr 2005 00:07:35 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-100.dti.cegetel.net [217.19.192.100]) by smtp.cegetel.net (Postfix) with SMTP id B145A67444; Thu, 14 Apr 2005 09:07:28 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Thu, 14 Apr 2005 09:07:29 +0200 (CEST) Message-ID: <1518.82.127.77.43.1113462449.squirrel@ssl-webmail.sitadelle.com> Date: Thu, 14 Apr 2005 09:07:29 +0200 (CEST) Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments From: "Thomas Broyer" To: In-Reply-To: <425DE586.3030009@franklinmint.fm> References: <42579382.3040003@gmx.de> <2f51d7d3708a263570d3a81833f7fb25@iki.fi> <425C4588.2010302@franklinmint.fm> <87ekdhqd7w.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87k6n9rub9.fsf@nwalsh.com> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <425D9245.6090203@franklinmint.fm> <425DE586.3030009@franklinmint.fm> X-Priority: 3 Importance: Normal Cc: , X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > [snip: an example with mixed XHTML and MicroSoft stuff] > > Thank you, Asbjørn: this is a delightful little problem. You see, XHTML > validity is specified in terms of DTDs. Near as I can tell, that example > and some of the XHTML examples in the spec are 'invalid' because the > local names don't match the DTD, and there are stray xmlns declarations. > If any of the current versions of XHTML allow that, we should probably > point to that one, but I don't know if any of them do. Well, I think an XML Schema defined XHTML [1] would allow xmlns declarations but if you want to include "foreign" elements and attributes in XHTML, it'll never be valid, except if you write your own XHTML Module and/or hybrid document type (like the XHTML+MathML+SVG Profile [2]). However, Atom requires wellformedness, not validity. So your wording, Rob, seems good to me (even if I still disagree with the div wrapper...): > If the value of "type" is "xhtml", the content of the Text construct > MUST be a single XHTML div element [XHTML transitional reference], and > SHOULD be suitable for handling as XHTML. The reference should IMHO point to both XHTML 1.0 (allows the lang and name attributes) and XHTML 1.1 (allows ruby), i.e. having two XHTML references. The day XHTML will have an RNG modularized schema (seems to be the case for XHTML 2.0, but we need XHTML 1.x), Atom would be able to precisely define (still informative as the Atom RNC schema is not normative) the content model of the Text Constructs, e.g. extending XHTML with xsd:any and xsd:anyAttribute (I don't know how to say that in RelaxNG). [1] http://www.w3.org/TR/xhtml1-schema/ [2] http://www.w3.org/TR/XHTMLplusMathMLplusSVG -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Apr 14 08:24:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06154 for ; Thu, 14 Apr 2005 08:24:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EC4g0l002238; Thu, 14 Apr 2005 05:04:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EC4gUj002237; Thu, 14 Apr 2005 05:04:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3EC4eos002188 for ; Thu, 14 Apr 2005 05:04:41 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 38467 messnum 5387483 invoked from network[213.94.211.166/dev2.mcpps.com]); 14 Apr 2005 12:04:34 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail08.svc.cra.dublin.eircom.net (qp 38467) with SMTP; 14 Apr 2005 12:04:34 -0000 Message-ID: <425E5C50.9090301@dehora.net> Date: Thu, 14 Apr 2005 13:04:32 +0100 From: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren CC: Norman Walsh , atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425D5F91.9040809@annevankesteren.nl> In-Reply-To: <425D5F91.9040809@annevankesteren.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > > Norman Walsh wrote: >> >> | XHTML 2 does have a different namespace. >> >> Ouch. I had forgotten or failed to notice that. > > > Yeah, using namespaces for versioning sucks... > >> >> I don't have any. I'll tailor my content to suit what the major >> vendors support, just like I do with my plain old HTML today. In >> practice, my feeds contain no markup at all (because I'm still >> generating RSS and I will not produce escaped markup). > > > I don't really like this point of view. This is exactly what creates > interoperability problems and people will blame Atom in the end for > promising to solve problems it does not. I don't think is comes under the category of namespaces for versioning problem. We made this problem ourselves, due to the consensus view that says default namespaces are so valuable we have the bake an inverted dependency into Atom, ie the feature of having to have Atom know about XHTML to treat it special is arguably a design problem. And our answer to the consequences of the self-made design problem is to design a registry? I don't see that as a simplifying move. If there is not a tidy way out of this, or we don't just agree to scope it as a point solution for a particular flavour of XHTML, I suggest we revisit the xhtml:div approach altogether. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 14 11:00:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22302 for ; Thu, 14 Apr 2005 11:00:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EEphNJ028374; Thu, 14 Apr 2005 07:51:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EEph51028373; Thu, 14 Apr 2005 07:51:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EEpgAU028366 for ; Thu, 14 Apr 2005 07:51:43 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:61571 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228851AbVDNOvl (ORCPT ); Thu, 14 Apr 2005 17:51:41 +0300 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <1518.82.127.77.43.1113462449.squirrel@ssl-webmail.sitadelle.com> References: <42579382.3040003@gmx.de> <2f51d7d3708a263570d3a81833f7fb25@iki.fi> <425C4588.2010302@franklinmint.fm> <87ekdhqd7w.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87k6n9rub9.fsf@nwalsh.com> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <425D9245.6090203@franklinmint.fm> <425DE586.3030009@franklinmint.fm> <1518.82.127.77.43.1113462449.squirrel@ssl-webmail.sitadelle.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <49af7c2ff3478ec454dc2f5aecfcb10d@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Date: Thu, 14 Apr 2005 17:51:20 +0300 To: "Atom-Syntax Syntax'" X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 14, 2005, at 10:07, Thomas Broyer wrote: > [1] http://www.w3.org/TR/xhtml1-schema/ For the record, James Clark has made Relax NG schemas for some flavors of XHTML 1.x. Surely James Clark is at least as good an authority as the W3C. :-) http://www.thaiopensource.com/relaxng/xhtml/ -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Thu Apr 14 14:07:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07565 for ; Thu, 14 Apr 2005 14:07:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EHqNZQ044559; Thu, 14 Apr 2005 10:52:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EHqNCl044558; Thu, 14 Apr 2005 10:52:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EHqML5044549 for ; Thu, 14 Apr 2005 10:52:22 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc11) with SMTP id <2005041417521701300kntpve>; Thu, 14 Apr 2005 17:52:17 +0000 Date: Thu, 14 Apr 2005 11:52:15 -0600 Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <425E5C50.9090301@dehora.net> Message-Id: X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3EHqNL5044552 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thursday, April 14, 2005, at 06:04 AM, Bill de hÓra wrote: > I don't think is comes under the category of namespaces for versioning > problem. We made this problem ourselves, due to the consensus view > that says default namespaces are so valuable we have the bake an > inverted dependency into Atom, ie the feature of having to have Atom > know about XHTML to treat it special is arguably a design problem. Looking at a Blogger-generated Atom 0.3 feed:
The package for my son's diapers says "22-37 lbs", but there is absolutely no way they could hold that much stuff without leaking!
 ...so we certainly didn't create the problem by requiring the div--xmlns attributes were being added to
s in Atom feeds before we came up with the idea. What we've discovered is that there is no way to make the XHTML namespace the default namespace while having the content be a valid XHTML fragment. We'd have to allow the element inside of atom:content to do that. Other options include not worrying about whether the content is valid XHTML (though of course it must be well-formed XML), or only requiring that the content of the div be a valid XHTML fragment, and not the div itself, which, since the div isn't part of the content, wouldn't be entirely strange. From owner-atom-syntax@mail.imc.org Thu Apr 14 14:48:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11451 for ; Thu, 14 Apr 2005 14:48:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EIcgWh048773; Thu, 14 Apr 2005 11:38:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EIcgFH048772; Thu, 14 Apr 2005 11:38:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EIceL4048764 for ; Thu, 14 Apr 2005 11:38:41 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.65.189]) by smtp.cegetel.net (Postfix) with ESMTP id 5B6C73822B; Thu, 14 Apr 2005 20:38:34 +0200 (CEST) Message-ID: <425EB8A8.7070306@cegetel.net> Date: Thu, 14 Apr 2005 20:38:32 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Henri Sivonen Cc: "Atom-Syntax Syntax'" Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: <42579382.3040003@gmx.de> <2f51d7d3708a263570d3a81833f7fb25@iki.fi> <425C4588.2010302@franklinmint.fm> <87ekdhqd7w.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87k6n9rub9.fsf@nwalsh.com> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <425D9245.6090203@franklinmint.fm> <425DE586.3030009@franklinmint.fm> <1518.82.127.77.43.1113462449.squirrel@ssl-webmail.sitadelle.com> <49af7c2ff3478ec454dc2f5aecfcb10d@iki.fi> In-Reply-To: <49af7c2ff3478ec454dc2f5aecfcb10d@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henri Sivonen wrote: > > On Apr 14, 2005, at 10:07, Thomas Broyer wrote: > >> [1] http://www.w3.org/TR/xhtml1-schema/ > > > For the record, James Clark has made Relax NG schemas for some flavors > of XHTML 1.x. Surely James Clark is at least as good an authority as the > W3C. :-) > > http://www.thaiopensource.com/relaxng/xhtml/ So Atom could propose a Relax NG schema that could validate the included XHTML as well! And as the Atom Relax NG schema is not normative and the text would say the content SHOULD be "valid" XHTML, if one want to use invalid XHTML, his feed is still valid Atom. If I understand RNG and RNC correctly, the schema would say something like: include http://www.thaiopensource.com/relaxng/xhtml/modules/text.rng { Inline.class |= element * - atom:* - xhtml:* Block.class |= element * - atom:* - xhtml:* Core.attrib &= attribute * - atom:* - xhtml:* { text }* } # Include here every other needed XHTML schema # should be all except struct.rng and frames.rng, and evenly legacy.rng # define the xhtmlDiv used by Text Constructs and atom:content # it might be needed to redefine allowed attributes xhtmlDiv = xhtml:div # if we want to get rid of the div wrapper, use sth like that instead: # xhtmlDiv = div.attlist, Flow.model -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Apr 14 15:13:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13754 for ; Thu, 14 Apr 2005 15:13:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EJ1mRt050687; Thu, 14 Apr 2005 12:01:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EJ1moK050686; Thu, 14 Apr 2005 12:01:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EJ1lKR050667 for ; Thu, 14 Apr 2005 12:01:47 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.65.189]) by smtp.cegetel.net (Postfix) with ESMTP id 6501867617 for ; Thu, 14 Apr 2005 21:01:41 +0200 (CEST) Message-ID: <425EBE15.8050706@cegetel.net> Date: Thu, 14 Apr 2005 21:01:41 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: PaceRecommendPlainTextContent: another "dangerous tags" example Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This a far less "exotic" "dangerous tags" example for PaceRecommendPlainTextContent:
We are offering a 15 euros rebate on our last product!
Said that, I'm -1 on this Pace. I'd rather go for guidelines (in an informative appendix?) on those "subtleties" (there aren't much actually) when transforming (X)HTML markup to plain text. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Apr 14 15:18:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14488 for ; Thu, 14 Apr 2005 15:18:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EJ7p2i051044; Thu, 14 Apr 2005 12:07:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EJ7pf0051043; Thu, 14 Apr 2005 12:07:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EJ7oY5051034 for ; Thu, 14 Apr 2005 12:07:50 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DM9gj-0003Yb-Ax; Thu, 14 Apr 2005 19:07:41 +0000 Message-ID: <425EBF72.2090508@franklinmint.fm> Date: Thu, 14 Apr 2005 15:07:30 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= CC: Anne van Kesteren , Norman Walsh , atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425D5F91.9040809@annevankesteren.nl> <425E5C50.9090301@dehora.net> In-Reply-To: <425E5C50.9090301@dehora.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > If there is not a tidy way out of this, or we don't just agree to > scope it as a point solution for a particular flavour of XHTML, I > suggest we revisit the xhtml:div approach altogether. Bill, I don't think the problem is exclusive to the outer div. I can't find any version of XHTML that allows where xh is bound to the XHTML namespace URI. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 14 16:13:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20059 for ; Thu, 14 Apr 2005 16:13:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EK2BCt054927; Thu, 14 Apr 2005 13:02:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EK2BdY054926; Thu, 14 Apr 2005 13:02:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EK2A7F054916 for ; Thu, 14 Apr 2005 13:02:11 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc13) with SMTP id <2005041420020501600ar72qe>; Thu, 14 Apr 2005 20:02:05 +0000 Date: Thu, 14 Apr 2005 14:02:03 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: RE: One reason we have duplicates entries is that we have duplicate feeds... From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <11E25F3D-AD20-11D9-9590-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ...back in town, and ready to express opinions... > Thomas Broyer wrote: >> Bob Wyman wrote: >>> Robert Sayre wrote: >>> You can point to an alternate feed like this >>> >>> Of course, you can't have two alternates with the same media type... >> >> Yes, you can point to an alternate. However, all you are doing at >> that point is establishing equivalence between the two. The >> "alternate" >> mechanism doesn't provide you with a way to say which feed is >> preferred. >> > Well, if you publish Atom 1.0, RSS 1.0 and RSS 2.0 feeds, they should > all be equivalent. Which is "preferred" is on the end-user's hands. I disagree that they're necessarily equivalent--the publisher may consider one to be the "original" feed, and all others to be alternative versions of it, and in fact the secondary feeds may very well be generated by transforming the primary feed. That needn't necessarily affect which one an individual subscriber subscribes to. The point is that it would be useful (for duplicate detection) for the publisher to be able to indicate that they consider a particular feed to be a secondary source of data to another feed or feeds, either because it's an alternative format of all the same data, or because it is or contains a subset of data from another feed or feeds. I think we could get by without @rel="preferred-feed" and the baggage that wording carries, and just use @rel="subset-of" for all cases. That wouldn't precisely express the idea that the feed in question is secondary to another feed, so we might want a different value like "secondary-to", "primary-feed", "primary-source" or something. There are three cases this may need to address: feeds that are strict subsets of other feeds, feeds that are alternative format versions of other feeds, and feeds that are aggregated from multiple other feeds. We've already got a way to handle aggregations from multiple sources. Do we want to allow people to choose to just use a "secondary-to" link to express that relationship rather than atom:source-feed with it's copy of the feed metadata? Just asking because it's conceivable that it might happen. Alternative format versions are the best candidate for handling with a single link, because other than the format that's carrying the data, they're the same thing--their feed level metadata should be identical (or as identical as the various formats are capable of expressing). Strict subsets on the other hand might have very different feed level metadata, which would make using atom:source-feed to express them as aggregations (even though they're from a single source) more technically accurate. But since each entry would have to have an identical copy of atom:source-feed in that case, it would be a little sloppy. Antone From owner-atom-syntax@mail.imc.org Thu Apr 14 17:35:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02909 for ; Thu, 14 Apr 2005 17:35:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3ELB6xM059608; Thu, 14 Apr 2005 14:11:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3ELB6Xx059607; Thu, 14 Apr 2005 14:11:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3ELB4Gq059584 for ; Thu, 14 Apr 2005 14:11:05 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 58578 messnum 3323944 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 14 Apr 2005 21:10:58 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail05.svc.cra.dublin.eircom.net (qp 58578) with SMTP; 14 Apr 2005 21:10:58 -0000 Message-ID: <425EDC5E.4060606@dehora.net> Date: Thu, 14 Apr 2005 22:10:54 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Antone Roundy wrote: > > On Thursday, April 14, 2005, at 06:04 AM, Bill de hÓra wrote: > >> I don't think is comes under the category of namespaces for versioning >> problem. We made this problem ourselves, due to the consensus view >> that says default namespaces are so valuable we have the bake an >> inverted dependency into Atom, ie the feature of having to have Atom >> know about XHTML to treat it special is arguably a design problem. > > > Looking at a Blogger-generated Atom 0.3 feed: > > xml:base="http://antone.geckotribe.com/bustedworld/" xml:space="preserve"> >
The package for my son's > diapers says "22-37 lbs", but there is absolutely no way they > could hold that much stuff without leaking!
> > > ...so we certainly didn't create the problem by requiring the div--xmlns > attributes were being added to
s in Atom feeds before we came up > with the idea. What we've discovered is that there is no way to make > the XHTML namespace the default namespace while having the content be a > valid XHTML fragment. We'd have to allow the element inside of > atom:content to do that. Other options include not worrying about > whether the content is valid XHTML (though of course it must be > well-formed XML), or only requiring that the content of the div be a > valid XHTML fragment, and not the div itself, which, since the div isn't > part of the content, wouldn't be entirely strange. I didn't follow that Antone, sorry, but... until I understand what you're saying, I'll hold my position that an enveloping format like Atom having to special case XHTML payloads is design problem because the dependencies are travelling in the wrong direction. XHTML in the wild notwithstanding if we spec it in, it's our problem. I do take what into account what Robert said about XHTML and prefixes, btw, but I wonder how much of this goes away if Atom does not use default namespaces. And while I do realize that XML in XML tends be a broader problem that just Atom, one counter-example on prefixed Atom+XHTML not working would probably shut me up. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 14 18:09:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05937 for ; Thu, 14 Apr 2005 18:09:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3ELwGdt062901; Thu, 14 Apr 2005 14:58:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3ELwGUq062900; Thu, 14 Apr 2005 14:58:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3ELwGD7062880 for ; Thu, 14 Apr 2005 14:58:16 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc12) with SMTP id <2005041421581001400h9l34e>; Thu, 14 Apr 2005 21:58:10 +0000 Date: Thu, 14 Apr 2005 15:58:05 -0600 Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <425EDC5E.4060606@dehora.net> Message-Id: <474B41C5-AD30-11D9-9590-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3ELwGD7062895 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Thursday, April 14, 2005, at 03:10 PM, Bill de hÓra wrote: > Antone Roundy wrote: >> Looking at a Blogger-generated Atom 0.3 feed: >> > xml:base="http://antone.geckotribe.com/bustedworld/" >> xml:space="preserve"> >>
The package for my son's >> diapers says "22-37 lbs", but there is absolutely no way they >> could hold that much stuff without leaking!
>> >> ...so we certainly didn't create the problem by requiring the >> div--xmlns attributes were being added to
s in Atom feeds before >> we came up with the idea. What we've discovered is that there is no >> way to make the XHTML namespace the default namespace while having >> the content be a valid XHTML fragment. We'd have to allow the >> element inside of atom:content to do that. Other options include not >> worrying about whether the content is valid XHTML (though of course >> it must be well-formed XML), or only requiring that the content of >> the div be a valid XHTML fragment, and not the div itself, which, >> since the div isn't part of the content, wouldn't be entirely >> strange. > > I didn't follow that Antone I'll see if I can be more clear on the points I was making: 1) Blogger-generated Atom 0.3 feeds, which predate the requirement to have an xhtml:div inside atom:content when @type="xhtml" have an xmlns attribute (which is not "valid" in xhtml). So the div requirement didn't create the problem of people putting invalid XHTML fragments into atom:content as had been asserted. 2) Because xhtml:div in valid XHTML can't have an xmlns attribute (that's what started this whole discussion, right?), the XHTML namespace has to be declared on or outside of atom:content--it can't be declared inside of atom:content--unless we don't care that the contents of atom:content are not valid XHTML. Note the following two excerpts from http://www.w3.org/TR/xhtml1/#well-formed, which legitimize doing exactly what's being done in Atom 0.3...just with

instead of

: =================== The XHTML namespace may be used with other XML namespaces as per [XMLNS], although such documents are not strictly conforming XHTML 1.0 documents as defined above. =================== ...of course, we're not trying to create "strictly conforming XHTML 1.0 documents", we're creating Atom documents with XHTML 1.0 fragments embedded in them. =================== The following example shows the way in which XHTML 1.0 markup could be incorporated into another XML namespace: Cheaper by the Dozen 1568491379

This is also available online.

=================== 3) I erred in my earlier assertion that this makes it impossible to make the XHTML namespace the default namespace, but it makes it sloppy. Examples of how it could be done: ...
This is XHTML content,
and the default namespace is XHTML's.
 or ...
This is XHTML content,
and the default namespace is XHTML's.
 4) Another option (which I would NOT be in favor of) would be to allow xhtml:html in atom:content, since xhtml:html CAN have an xmlns attribute. For example: ...
This is XHTML content,
and the default namespace is XHTML's.
 > I do take what into account what Robert said about XHTML and prefixes I'm not sure which comment you're referring to. The one comment I found, I had interpreted to mean that in XHTML,

can't be empty, as in

(http://www.w3.org/TR/xhtml1/#h-4.3 : "All elements other than those declared in the DTD as EMPTY must have an end tag. Elements that are declared in the DTD as EMPTY can have an end tag or can use empty element shorthand"). If the point was that XHTML requires the XHTML namespace to be the default, then I was unable to find any place where that was specified. > but I wonder how much of this goes away if Atom does not use default > namespaces. Perhaps all of it. But I'm still emotionally attached to default namespaces. ;-) Antone From owner-atom-syntax@mail.imc.org Thu Apr 14 18:11:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06108 for ; Thu, 14 Apr 2005 18:11:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EM1JXh063114; Thu, 14 Apr 2005 15:01:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EM1JD4063113; Thu, 14 Apr 2005 15:01:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wvmler3.mail.xerox.com (wvmler3.mail.xerox.com [13.8.138.218]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EM1J24063107 for ; Thu, 14 Apr 2005 15:01:19 -0700 (PDT) (envelope-from Leigh.Klotz@xerox.com) Received: from wvmlir1.mail.xerox.com (wvmlir1.mail.xerox.com [13.147.8.221]) by wvmler3.mail.xerox.com (8.13.2/8.13.1) with ESMTP id j3EM0x0p010161; Thu, 14 Apr 2005 15:01:02 -0700 Received: from wvmlir1.mail.xerox.com (localhost [127.0.0.1]) by wvmlir1.mail.xerox.com (8.13.2/8.13.1) with ESMTP id j3EM0wsH029690; Thu, 14 Apr 2005 15:00:58 -0700 Received: from usa7061gw03.na.xerox.net (usa7061gw03.na.xerox.net [13.151.32.5]) by wvmlir1.mail.xerox.com (8.13.2/8.13.1) with ESMTP id j3EM0wox029685; Thu, 14 Apr 2005 15:00:58 -0700 Received: from usa7061ms01.na.xerox.net ([13.151.34.2]) by usa7061gw03.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 14 Apr 2005 15:00:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Date: Thu, 14 Apr 2005 15:00:57 -0700 Message-ID: Thread-Topic: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Thread-Index: AcVBOzkhC0Tr6DuPQc6dsGvdACdUWQAAdWgQ From: "Klotz, Leigh" To: =?iso-8859-1?Q?Bill_de_h=D3ra?= , X-OriginalArrivalTime: 14 Apr 2005 22:00:57.0795 (UTC) FILETIME=[70028130:01C5413D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3EM1J24063108 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I think that casting this problem as XML-in-XML is a problem in itself, and I believe that a more productive approach is to consider it a mixed-namespace document with extensibility as in CDF, and use RNG for the formal description. -----Original Message----- Bill de hÓra>...And while I do realize that XML in XML tends be a broader problem that just Atom... From owner-atom-syntax@mail.imc.org Thu Apr 14 18:14:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06599 for ; Thu, 14 Apr 2005 18:14:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EM0e6c063063; Thu, 14 Apr 2005 15:00:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EM0egQ063062; Thu, 14 Apr 2005 15:00:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EM0dmh063054 for ; Thu, 14 Apr 2005 15:00:39 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.65.189]) by smtp.cegetel.net (Postfix) with ESMTP id 13DCF38057; Fri, 15 Apr 2005 00:00:33 +0200 (CEST) Message-ID: <425EE801.1010204@cegetel.net> Date: Fri, 15 Apr 2005 00:00:33 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: mint@franklinmint.fm Cc: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= , Anne van Kesteren , Norman Walsh , atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425D5F91.9040809@annevankesteren.nl> <425E5C50.9090301@dehora.net> <425EBF72.2090508@franklinmint.fm> In-Reply-To: <425EBF72.2090508@franklinmint.fm> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > I can't find any version of XHTML that allows where xh is > bound to the XHTML namespace URI. ]> This does not a strictly conforming XHTML 1.1 document as defined in XHTML 1.1, section 2.1.1. Strictly Conforming Documents but it is a valid XML document, using the XHTML 1.1 DTD. ...and this is the case only when validating against a DTD. Validating against the XML Schema [1] will allow any kind of prefix to be bound to the XHTML namespace: This document is valid against the XHTML 1.0 XML Schema, without any trickery. I believe the same thing happens (no needed trickery) when using a Relax NG schema, like the ones by James Clark. [1] http://www.w3.org/TR/xhtml1-schema/ -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Apr 14 18:22:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07437 for ; Thu, 14 Apr 2005 18:22:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EM7vb9063550; Thu, 14 Apr 2005 15:07:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EM7vGr063549; Thu, 14 Apr 2005 15:07:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EM7u2P063536 for ; Thu, 14 Apr 2005 15:07:57 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.65.189]) by smtp.cegetel.net (Postfix) with ESMTP id 0DC0267283; Fri, 15 Apr 2005 00:07:51 +0200 (CEST) Message-ID: <425EE9BC.7050606@cegetel.net> Date: Fri, 15 Apr 2005 00:07:56 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > What we've discovered is that there is no way to make the XHTML > namespace the default namespace while having the content be a valid > XHTML fragment. We'd have to allow the element inside of > atom:content to do that. Even if you were allowing the html element inside atom:content, it wouldn't be "valid XHTML": - it is not a Strictly Conforming Document [1] since the html element is not the root element (it's a child of atom:content) - neither it is a valid XML document since Atom doesn't provide a DTD [1] http://www.w3.org/TR/xhtml1/#strict -- Thomas Broyer From owner-atom-syntax@mail.imc.org Thu Apr 14 18:48:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09219 for ; Thu, 14 Apr 2005 18:48:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EMe60O068038; Thu, 14 Apr 2005 15:40:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3EMe6C9068037; Thu, 14 Apr 2005 15:40:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3EMe6Yo068030 for ; Thu, 14 Apr 2005 15:40:06 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DMD0D-0006PW-Ax; Thu, 14 Apr 2005 22:40:01 +0000 Message-ID: <425EF136.8050809@franklinmint.fm> Date: Thu, 14 Apr 2005 18:39:50 -0400 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: atom-syntax@imc.org Subject: Test documents (was:Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments) References: <425EDC5E.4060606@dehora.net> In-Reply-To: <425EDC5E.4060606@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > while I do realize that XML in XML tends be a broader problem that just > Atom, one counter-example on prefixed Atom+XHTML not working would > probably shut me up. I'm not looking to shut you up, but I thought I'd do some experiments. The two feeds below are identical (save atom:id). They each contain two entries with equivalent content, except one entry has prefixed XHTML content. You should see bold and italics in the content of both entries. The prefixed content doesn't work in Bloglines... :/ Here you go, folks: Atom 0.3 served as text/xml: http://www.franklinmint.fm/2005/04/14/prefixtest.xml Atom 0.3 served as application/atom+xml: http://www.franklinmint.fm/2005/04/14/prefixtest.atom Some html, just for fun: XHTML served as text/html: http://www.franklinmint.fm/2005/04/14/prefixed.html XHTML served as application/xhtml+xml: http://www.franklinmint.fm/2005/04/14/prefixed.xhtml Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 14 19:37:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11767 for ; Thu, 14 Apr 2005 19:37:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3ENOW6B071439; Thu, 14 Apr 2005 16:24:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3ENOWAL071438; Thu, 14 Apr 2005 16:24:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3ENOVLr071429 for ; Thu, 14 Apr 2005 16:24:32 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3ENNfHl020363; Fri, 15 Apr 2005 00:23:47 +0100 (BST) In-Reply-To: <425EF136.8050809@franklinmint.fm> References: <425EDC5E.4060606@dehora.net> <425EF136.8050809@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <13e629856ac079c728e0f2ed38d5c057@mac.com> Content-Transfer-Encoding: 7bit Cc: atom-Syntax From: Graham Subject: Re: Test documents (was:Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments) Date: Fri, 15 Apr 2005 00:23:38 +0100 To: mint@franklinmint.fm X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 14 Apr 2005, at 11:39 pm, Robert Sayre wrote: > The two feeds below are identical (save atom:id). They each contain > two entries with equivalent content, except one entry has prefixed > XHTML content. You should see bold and italics in the content of both > entries. The prefixed content doesn't work in Bloglines... :/ I'd suggest that's because Bloglines is broken, and that we need a prefixed example in the spec. (Disclosure: Shrook is also broken in this regard, but it will be fixed for Atom 1.0) Graham From owner-atom-syntax@mail.imc.org Thu Apr 14 20:45:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16505 for ; Thu, 14 Apr 2005 20:45:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F0ZX7Q076977; Thu, 14 Apr 2005 17:35:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3F0ZXLD076976; Thu, 14 Apr 2005 17:35:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3F0ZWmb076966 for ; Thu, 14 Apr 2005 17:35:33 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 93664 messnum 6385620 invoked from network[83.70.250.230/83-70-250-230.b-ras1.prp.dublin.eircom.net]); 15 Apr 2005 00:35:26 -0000 Received: from 83-70-250-230.b-ras1.prp.dublin.eircom.net (HELO ?127.0.0.1?) (83.70.250.230) by mail00.svc.cra.dublin.eircom.net (qp 93664) with SMTP; 15 Apr 2005 00:35:26 -0000 Message-ID: <425F0C4C.9000803@dehora.net> Date: Fri, 15 Apr 2005 01:35:24 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Klotz, Leigh" CC: atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Klotz, Leigh wrote: > I think that casting this problem as XML-in-XML is a problem in itself, It's a problem, but I don't see as casting. But like I said, if that's not the technical problem, I'll gladly shut up. If it is, we could do worse than be cognizant as to what we're working around. > and I believe that a more productive approach is to consider it a mixed-namespace document > with extensibility as in CDF, and use RNG for the formal description. Except that strictly speaking the rng is informative and won't count formally (altho' it's a nice approach). We'd have to spec it as text. cheers Bill From owner-atom-syntax@mail.imc.org Fri Apr 15 04:19:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05360 for ; Fri, 15 Apr 2005 04:19:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8BMh2079069; Fri, 15 Apr 2005 01:11:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3F8BM36079068; Fri, 15 Apr 2005 01:11:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3F8BJiY078986 for ; Fri, 15 Apr 2005 01:11:22 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEZ000DOAHAC050@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Fri, 15 Apr 2005 10:05:34 +0200 (CEST) Received: from quark ([80.203.88.140]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IEZ006KNASQBX60@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Fri, 15 Apr 2005 10:12:27 +0200 (CEST) Date: Fri, 15 Apr 2005 10:14:06 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Using namespaces instead of 'type' (was: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments) In-reply-to: <474B41C5-AD30-11D9-9590-003065EA6144@geckotribe.com> To: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <474B41C5-AD30-11D9-9590-003065EA6144@geckotribe.com> User-Agent: Opera M2(BETA2)/8.0 (Win32, build 7483) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Thu, 14 Apr 2005 23:58:05 +0200, Antone Roundy wrote: > >

This is XHTML content,
> and the default namespace is XHTML's.
> This example made me think about another solution for the Content Constructs of Atom. Today, they all reside in the Atom namespace, which of course, makes most sense. But even though I see it is a major hack, won't putting Content Constructs inside the target namespace of the embedded content be a solution to tell what type of content we are embedding without having to use a 'type' element? Example: ...

Booyah! This is an XHTML fragment.

 Since Atom consumers need to have special handling for each 'type' ('html', 'xhtml', 'text') we provide today, we might as well imho signify this with the XHTML namespace as with a 'type' attribute. The problem is that it's difficult to say «this is to be parsed as escaped SGML» in contrary to «this is to be read as plain text». Alas, we need a solution for non-XML types in Atom if we think using namespaces is a good enough solution for XML types. If we take the hack even further, we could create pseudo namespaces for text and HTML types as well. Or perhaps even a general SGML namespace. So when we want to embed text in Content Constructs, we do it like this: *Booyah! This is an text fragment.* And when we want to embed HTML, we do it like this: <h1>Booyah! This is an text fragment.</h1> I've already mentioned that I think this solution is a hack, and I'm not sure I like it, but what I do like about it is that it gives us a general way to deal with XML content that is much simpler (imho at least) than any other previous solution (which have included 'type', 'mode' and various other attributes). Yes, there is no element called 'xhtml:content' in the XHTML specification, but we won't have _valid_ (although wellformed) XHTML in Atom anyways, so why strive so hard to reach something we won't reach anyway? The XHTML content in Atom will be valid XML. It can't ever be valid XHTML. Let's just settle with that and move forward, no? -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Apr 15 11:23:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08901 for ; Fri, 15 Apr 2005 11:23:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FFBlRh081446; Fri, 15 Apr 2005 08:11:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FFBlbs081445; Fri, 15 Apr 2005 08:11:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FFBkFs081367 for ; Fri, 15 Apr 2005 08:11:47 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc13) with SMTP id <2005041515114001500h4ivbe>; Fri, 15 Apr 2005 15:11:40 +0000 Date: Fri, 15 Apr 2005 09:11:39 -0600 Subject: Re: Using namespaces instead of 'type' (was: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3FFBlFs081439 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Friday, April 15, 2005, at 02:14 AM, Asbjørn Ulsberg wrote: > But even though I see it is a major hack, won't putting Content > Constructs inside the target namespace of the embedded content be a > solution to tell what type of content we are embedding without having > to use a 'type' element? I think we're better off sticking with the solution suggested in the XHTML spec, where the XHTML namespace is declared on the top level XHTML element. Unlike their example,
is a better element to use there than

(if we wish to standardize on one), because the content may contain multiple paragraphs, and

can encompass multiple paragraphs. Finally, *requiring* the div and specifying that it's not to be treated as part of the content clarifies what would otherwise be the ambiguous status of the outermost element inside atom:content. Note that for other XML types, things are still ambiguous: > 4. If the value of "type" ends with "+xml" or "/xml" > (case-insensitive), the content of atom:content may include > child > elements, and SHOULD be suitable for handling as the indicated > media type. If the "src" attribute is not provided, this would > normally mean that the "atom:content" element would contain a > single child element which would serve as the root element of > the > XML document of the indicated type. So we don't know whether we have a full document or a fragment, nor whether the outermost child element (if there IS only one) is a throwaway container or a keeper. An idea that just popped into my head would be to add one attribute to atom:content (and perhaps text constructs) to specify how to handle XML content...don't we just love adding new attributes! For example (pulling a name out of the air):
This is XHTML content in a throwaway div. Any attributes on that div that aren't handled by the XML processor are at risk of being lost, so adding styles there, for example, is not a good idea. Depending on the XML processor the consumer uses, things like xml:lang may be preserved, but it would probably be wiser to put those elsewhere, on an element that isn't getting thrown away.
This is XHTML content in a div which IS part of the content.
This is the first paragraph of XHTML content with no container element inside atom:content. This is the second paragraph. Actually, "keep" and "none" would be processed identically--both treat everything inside atom:content as part of the content--so "none" could be used in both places. Arguments could be made for making either the default: Dispose: * Requires no changes to Atom feeds based on the current draft. * Requires no changes to Atom feeds following the current convention of putting XHTML content into a container div that appears to be getting added during serialization. None: * Arguably more precise for non-XML content (they don't have a container, so "dispose" would have to be interpreted as "if there IS an immediate child element, dispose of it" to exactly make sense). * Doesn't require action based on a non-specified attribute--you only dispose of something if explicitly told to do so. Hmm, I just noticed that I didn't create an example for differentiating between fragments and complete documents, but offhand, that doesn't feel necessary. Antone From owner-atom-syntax@mail.imc.org Fri Apr 15 14:17:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28285 for ; Fri, 15 Apr 2005 14:17:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FIAEfQ096580; Fri, 15 Apr 2005 11:10:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FIAEjg096579; Fri, 15 Apr 2005 11:10:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3FIACow096568 for ; Fri, 15 Apr 2005 11:10:13 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 15 Apr 2005 18:10:05 -0000 Received: from xdsl-213-196-254-132.netcologne.de (EHLO klangraum) [213.196.254.132] by mail.gmx.net (mp028) with SMTP; 15 Apr 2005 20:10:05 +0200 X-Authenticated: #163624 Date: Fri, 15 Apr 2005 20:12:55 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Message-ID: <20050415181255.GA24027@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <474B41C5-AD30-11D9-9590-003065EA6144@geckotribe.com> <425EDC5E.4060606@dehora.net> <474B41C5-AD30-11D9-9590-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <474B41C5-AD30-11D9-9590-003065EA6144@geckotribe.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Antone Roundy [2005-04-15 00:10]: > > ... > xmlns="XHTML's namespace URI"> >
This is XHTML content,
> and the default namespace is XHTML's.
> I like this. A lot. * Asbjørn Ulsberg [2005-04-15 10:20]: > Example: > > > ... > >

Booyah! This is an XHTML fragment.

> > > > […] > > If we take the hack even further, we could create pseudo > namespaces for text and HTML types as well. Ugh, no. @xmlns has well-defined meaning. I don’t think we should be overloading it this way. It seems to me that it would be best to just state that atom:content MAY have a @type whose value is 'text', 'html', or 'xml'. If absent it defaults to 'xml', and wWhen the effective value is 'xml', atom:content MUST contain XML data. What kind of data that is need not be further specified; it is determined by the namespace that the data is in. The approach proposed by Antone Roundy would be shown in the examples in the spec. That would get rid of one of the special cases. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Fri Apr 15 14:22:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28722 for ; Fri, 15 Apr 2005 14:22:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FIGDWn096911; Fri, 15 Apr 2005 11:16:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FIGDPg096910; Fri, 15 Apr 2005 11:16:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wvmler1.mail.xerox.com (wvmler1.mail.xerox.com [13.8.138.216]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FIGCHN096904 for ; Fri, 15 Apr 2005 11:16:12 -0700 (PDT) (envelope-from Leigh.Klotz@xerox.com) Received: from wvmlir2.mail.xerox.com (wvmlir2.mail.xerox.com [13.147.8.222]) by wvmler1.mail.xerox.com (8.13.2/8.13.1) with ESMTP id j3FIG1lY028736; Fri, 15 Apr 2005 11:16:06 -0700 Received: from wvmlir2.mail.xerox.com (localhost [127.0.0.1]) by wvmlir2.mail.xerox.com (8.13.2/8.13.1) with ESMTP id j3FIFe3h009710; Fri, 15 Apr 2005 11:15:40 -0700 Received: from usa7061gw03.na.xerox.net (usa7061gw03.na.xerox.net [13.151.32.5]) by wvmlir2.mail.xerox.com (8.13.2/8.13.1) with ESMTP id j3FIFaDx009705; Fri, 15 Apr 2005 11:15:40 -0700 Received: from usa7061ms01.na.xerox.net ([13.151.34.2]) by usa7061gw03.na.xerox.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 15 Apr 2005 11:15:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Date: Fri, 15 Apr 2005 11:15:35 -0700 Message-ID: Thread-Topic: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Thread-Index: AcVBUz6c4KRQ7/faSBK571XHQdoe0AAkyCBg From: "Klotz, Leigh" To: =?iso-8859-1?Q?Bill_de_h=D3ra?= Cc: X-OriginalArrivalTime: 15 Apr 2005 18:15:36.0600 (UTC) FILETIME=[1F29A180:01C541E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3FIGDHN096905 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill, Thank you for the answer. I'm being cautious here, because vocabulary integration is one of my main concerns in the direction Atom is taking, and I hate to see everything hard-coded with special deference to particular HTML tags. If we can't solve the problems without recourse to spec changes, we won't be building an extensible standard. Could you let me know why RNG can't be normative? Is it written down somewhere in the RFC? There's normative BNF in various IETF RFCs and I don't see much difference, especially since RNC looks like BNF and it's now an ISO standard. I do tend to disagree on the terminology issue, still, though. I think that saying we have an "XML-in-XML" problem leads people to think of encapsulation and semantic-blind content carrying (think base64 or CDATA), whereas calling it "mixed vocabulary" implies solutions that are at the semantic level, and I believe lead to extensibility. Dave Orchard and Dare Obasanjo have written eloquently on designing languages for for integration and extensibility [1] [2] [3]. The articles point out some obstacles in using XML Schema so I suggested RNG; although prose would work, it's more, well, wordy, and open to interpretation in the implementation. Leigh. [1] http://www.xml.com/pub/a/2003/12/03/versioning. [2] http://www.xml.com/pub/a/2004/07/21/design.html [3] htmlhttp://www.pacificspirit.com/blog/2004/07/27/dare%20versioning%20extensibility%20article%20comparison -----Original Message----- From: Bill de hÓra [mailto:bill@dehora.net] Sent: Thursday, April 14, 2005 4:35 PM To: Klotz, Leigh Cc: atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Klotz, Leigh wrote: > I think that casting this problem as XML-in-XML is a problem in itself, It's a problem, but I don't see as casting. But like I said, if that's not the technical problem, I'll gladly shut up. If it is, we could do worse than be cognizant as to what we're working around. > and I believe that a more productive approach is to consider it a mixed-namespace document > with extensibility as in CDF, and use RNG for the formal description. Except that strictly speaking the rng is informative and won't count formally (altho' it's a nice approach). We'd have to spec it as text. cheers Bill From owner-atom-syntax@mail.imc.org Fri Apr 15 16:16:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18738 for ; Fri, 15 Apr 2005 16:16:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FK6Ypm004673; Fri, 15 Apr 2005 13:06:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FK6Y9e004672; Fri, 15 Apr 2005 13:06:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FK6XlB004664 for ; Fri, 15 Apr 2005 13:06:33 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DMX57-0003Ae-BX; Fri, 15 Apr 2005 20:06:25 +0000 Message-ID: <42601EC1.1070806@franklinmint.fm> Date: Fri, 15 Apr 2005 16:06:25 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Klotz, Leigh" CC: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Klotz, Leigh wrote: > I'm being cautious here, because vocabulary integration is one of my > main concerns in the direction Atom is taking, and I hate to see > everything hard-coded with special deference to particular HTML tags. > If we can't solve the problems without recourse to spec changes, we > won't be building an extensible standard. Atom's content element allows arbitrary XML. Atom's Text construct does not. If the format were to allow basically anything in those, there wouldn't be much of a standard. > > Could you let me know why RNG can't be normative? Is it written down > somewhere in the RFC? There's normative BNF in various IETF RFCs and > I don't see much difference, especially since RNC looks like BNF and > it's now an ISO standard. There's no procedural reason, it was a working group decision. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Apr 15 16:34:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21952 for ; Fri, 15 Apr 2005 16:34:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FKS2ca006737; Fri, 15 Apr 2005 13:28:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FKS2Z5006736; Fri, 15 Apr 2005 13:28:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3FKS11A006714 for ; Fri, 15 Apr 2005 13:28:01 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 15 Apr 2005 20:27:55 -0000 Received: from xdsl-213-196-254-132.netcologne.de (EHLO klangraum) [213.196.254.132] by mail.gmx.net (mp001) with SMTP; 15 Apr 2005 22:27:55 +0200 X-Authenticated: #163624 Date: Fri, 15 Apr 2005 22:30:44 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Message-ID: <20050415203044.GA24845@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <474B41C5-AD30-11D9-9590-003065EA6144@geckotribe.com> <425EDC5E.4060606@dehora.net> <474B41C5-AD30-11D9-9590-003065EA6144@geckotribe.com> <20050415181255.GA24027@klangraum> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050415181255.GA24027@klangraum> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * A. Pagaltzis [2005-04-15 20:20]: > * Antone Roundy [2005-04-15 00:10]: > > > > ... > > > xmlns="XHTML's namespace URI"> > >
This is XHTML content,
> > and the default namespace is XHTML's.
> > > > I like this. A lot. One better, with my @type='xml' suggestion instead of @type='xhtml':

This is XHTML content.

The default namespace is XHTML's.

 That gets rid of the need to declare the atom: prefix over and over. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Fri Apr 15 17:03:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25277 for ; Fri, 15 Apr 2005 17:03:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FKrJKQ008716; Fri, 15 Apr 2005 13:53:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FKrJ0U008715; Fri, 15 Apr 2005 13:53:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FKrJ4G008640 for ; Fri, 15 Apr 2005 13:53:19 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc12) with SMTP id <20050415205313014006hk0ke>; Fri, 15 Apr 2005 20:53:13 +0000 Date: Fri, 15 Apr 2005 14:53:12 -0600 Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <20050415203044.GA24845@klangraum> Message-Id: <6150E036-ADF0-11D9-83B6-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, April 15, 2005, at 02:30 PM, A. Pagaltzis wrote: > > * A. Pagaltzis [2005-04-15 20:20]: >> * Antone Roundy [2005-04-15 00:10]: >>> >>> ... >>> >> xmlns="XHTML's namespace URI"> >>>
This is XHTML content,
>>> and the default namespace is XHTML's.
>>> >> >> I like this. A lot. > > One better, with my @type='xml' suggestion instead of > @type='xhtml': > > > > >

This is XHTML content.

>

The default namespace is XHTML's.

> > > > > That gets rid of the need to declare the atom: prefix over and > over. While this approach has it's appeal, I'm pretty sure I'm in favor of keeping "xhtml" as a special case for a few reasons: 1) I presume ("when you presume you make a pres of you and me"?) that XHTML is going to be by far the most common XML type used in atom:content, and least for a while. 2) It makes it more difficult to determine the type of data. We know it's XML, but to find out whether it's a flavor of XML that we know how to deal with, we have to discover the namespace of the content. That will sometimes be easy to determine, as in the example above, because the namespace is declared on the content element. However, sometimes, it may be done like this: This is XHTML content. The default namespace is XHTML's. In this case, we'd have to find a child element and check it's namespace. We've already discussed and rejected the idea of requiring namespaces to be declared at a particular point in Atom documents, so I think requiring to be declared in atom:content to make the type discovery easy has already been rejected. The alternative would be to use the full MIME type instead of just "xml" and use that instead of the namespace to discover the type. But there's still a problem... 3) Some people are still going to do it the way it's being done now, leaving us with the ambiguous status of the div. Is it part of the content or just a container? Antone From owner-atom-syntax@mail.imc.org Fri Apr 15 17:26:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27660 for ; Fri, 15 Apr 2005 17:26:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FLFUVK010355; Fri, 15 Apr 2005 14:15:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FLFU9F010354; Fri, 15 Apr 2005 14:15:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FLFUk1010324 for ; Fri, 15 Apr 2005 14:15:30 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc12) with SMTP id <20050415211525014006je2fe>; Fri, 15 Apr 2005 21:15:25 +0000 Date: Fri, 15 Apr 2005 15:15:23 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Trade mandatory xhtml:div for atom:content/@container? From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <7AF8BBD7-ADF3-11D9-83B6-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In case the idea was buried too deeply in my prior email[1], here it is in it's own message: Could we drop the xhtml:div requirement in content[@type="xhtml"], and instead clarify the status of the div that is commonly being put there (is it part of the content or not?) by adding an attribute to atom:content as follows:
This is XHTML content in a throwaway div.
 This is the first paragraph of XHTML content with no container element inside atom:content. This is the second paragraph.
This is XHTML content in a div which IS part of the content, assuming the default value for @container is "none".
If @container="dispose", atom:content MUST have a SINGLE child element which is NOT to be treated as part of the content, but is just a container. If @container="none" (or @container is omitted), then everything in atom:content is considered part of the content. @container="dispose" is only legal for XML types, whether "XHTML", or a MIME type ending in "/xml" or "+xml". Other than this being last minute, are there any drawbacks to this approach? Are there better names for the attribute? Better values for it? Is "none" a good default? [1] http://www.imc.org/atom-syntax/mail-archive/msg14228.html From owner-atom-syntax@mail.imc.org Fri Apr 15 17:56:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02866 for ; Fri, 15 Apr 2005 17:56:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FLnG3N012602; Fri, 15 Apr 2005 14:49:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FLnGtx012601; Fri, 15 Apr 2005 14:49:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3FLnEmp012588 for ; Fri, 15 Apr 2005 14:49:15 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 15 Apr 2005 21:49:08 -0000 Received: from xdsl-213-196-245-46.netcologne.de (EHLO klangraum) [213.196.245.46] by mail.gmx.net (mp031) with SMTP; 15 Apr 2005 23:49:08 +0200 X-Authenticated: #163624 Date: Fri, 15 Apr 2005 23:51:58 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Message-ID: <20050415215158.GA25195@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <20050415203044.GA24845@klangraum> <6150E036-ADF0-11D9-83B6-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6150E036-ADF0-11D9-83B6-003065EA6144@geckotribe.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Antone Roundy [2005-04-15 23:05]: > 2) It makes it more difficult to determine the type of data. > We know it's XML, but to find out whether it's a flavor of XML > that we know how to deal with, we have to discover the > namespace of the content. Good point, but it can be addressed. Bear with me, because this is going to get a bit long; but I believe my idea yields an elegant solution, eventually. Including the full MIME type is cruft, IMHO, in that it duplicates information that is already there. How about saying that the namespace associated with a particular prefix on the atom:content element level is to be consulted for the type of the content? In the simpler case, this could be supplied as an extra attribute, say @ns. The default namespace could be referred to using the special value '#default' (see XSLT for prior art), yielding something like

Hello, world.

 @ns here says that the namespace bound to the xh: prefix which is in effect from the atom:content element is to be considered the type of the content. Since the default namespace declared in situ applies to the atom:content element itself, and the default namespace is bound to the XHTML namespace URI, the content is XHTML. This means the following is possible just as well: Hello, world. Again, @ns says that the namespace bound to the xh: prefix which is in effect from the atom:content element is to be considered the type of the content. It is easier to see in this case that indeed that is XHTML. Finally, we can define @ns to have a default value of '#default', in which case a lot of people will not need to use @ns at all:

Hello, world.

 The only ones who need to be particularly careful then are those who create new feeds from existing feeds: they need to be careful to assign appropriate values for @ns attributes rather than just copying them thru blindly. This is not difficult; the necessary tools exist in XSLT/XPath, f.ex. > 3) Some people are still going to do it the way it's being done > now, leaving us with the ambiguous status of the div. Is it > part of the content or just a container? Is that really a great concern? Both semantically and presentionally, xhtml:div is neutral, so considering it to be part of the content does not change its interpretation. Thus, I don’t see any harm in eliding the issue altogether. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Fri Apr 15 17:59:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03040 for ; Fri, 15 Apr 2005 17:59:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FLro4i012936; Fri, 15 Apr 2005 14:53:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FLrotk012935; Fri, 15 Apr 2005 14:53:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3FLrmn2012922 for ; Fri, 15 Apr 2005 14:53:49 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 15 Apr 2005 21:53:42 -0000 Received: from xdsl-213-196-245-46.netcologne.de (EHLO klangraum) [213.196.245.46] by mail.gmx.net (mp011) with SMTP; 15 Apr 2005 23:53:42 +0200 X-Authenticated: #163624 Date: Fri, 15 Apr 2005 23:56:32 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: Trade mandatory xhtml:div for atom:content/@container? Message-ID: <20050415215632.GB25195@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <7AF8BBD7-ADF3-11D9-83B6-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7AF8BBD7-ADF3-11D9-83B6-003065EA6144@geckotribe.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Antone Roundy [2005-04-15 23:25]: > @container="dispose" is only legal for XML types, whether > "XHTML", or a MIME type ending in "/xml" or "+xml". Of course, @container would then obviate the need for treating XHTML any differently from other XML types (apart from the “how do I discover the type of the content†problem discussed in the previous thread). Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Fri Apr 15 18:22:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05477 for ; Fri, 15 Apr 2005 18:22:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FMF3u0014711; Fri, 15 Apr 2005 15:15:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FMF368014710; Fri, 15 Apr 2005 15:15:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FMF1hv014698 for ; Fri, 15 Apr 2005 15:15:02 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.32.139]) by smtp.cegetel.net (Postfix) with ESMTP id D853D37C2B; Sat, 16 Apr 2005 00:14:55 +0200 (CEST) Message-ID: <42603CF4.2020309@cegetel.net> Date: Sat, 16 Apr 2005 00:15:16 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: Trade mandatory xhtml:div for atom:content/@container? References: <7AF8BBD7-ADF3-11D9-83B6-003065EA6144@geckotribe.com> In-Reply-To: <7AF8BBD7-ADF3-11D9-83B6-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > Could we drop the xhtml:div requirement in content[@type="xhtml"], +1 > and instead clarify the status of the div that is commonly being put > there (is it part of the content or not?) +1 > by adding an attribute to atom:content -1 Let me explain my point of view: With @type="text" there is no container, neither with @type="html", so why should there be a container with @type="xhtml"? Just for carrying the xmlns declaration? Well, you'd better define it once in the feed element... Just to allow for prefix-free Atom documents? See below about "legacy Atom" documents. So what about those existing Atom documents (0.3 or draft-ietf-atompub-format-07) using a div container? Well, keep them as they are! What's the matter with having the entry content inside an XHTML div, itself being considered part of the content? A div element in (X)HTML has only a structural meaning. If the entry content is to be rendered as part of an XHTML document (as in a Web aggregator, or in a blog for example when Atom is used as a publishing protocol/syntax) and included inside a div element, the duplicate divs won't change anything to the document structure, there'll just be a needless duplicate div... So someone willing to use a div container in its Atom documents (e.g. to produce prefix-free documents, by declaring the XHTML namespace on the div) can do it as it won't change anything! -- Thomas Broyer From owner-atom-syntax@mail.imc.org Fri Apr 15 18:41:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06828 for ; Fri, 15 Apr 2005 18:41:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FMXAZm015812; Fri, 15 Apr 2005 15:33:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3FMXAkq015811; Fri, 15 Apr 2005 15:33:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3FMX9NL015794 for ; Fri, 15 Apr 2005 15:33:10 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc11) with SMTP id <2005041522330401300kuds6e>; Fri, 15 Apr 2005 22:33:04 +0000 Date: Fri, 15 Apr 2005 16:32:58 -0600 Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <20050415215158.GA25195@klangraum> Message-Id: <51A2E216-ADFE-11D9-83B6-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3FMXANL015806 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Friday, April 15, 2005, at 03:51 PM, A. Pagaltzis wrote: > * Antone Roundy [2005-04-15 23:05]: >> 2) It makes it more difficult to determine the type of data. >> We know it's XML, but to find out whether it's a flavor of XML >> that we know how to deal with, we have to discover the >> namespace of the content. ... > Including the full MIME type is cruft, IMHO, in that it > duplicates information that is already there. Not for non-XML data types, which don't have namespaces. > How about saying that the namespace associated with a particular > prefix on the atom:content element level is to be consulted for > the type of the content? In the simpler case, this could be > supplied as an extra attribute, say @ns. ...which "duplicates information that's already there." > The only ones who need to be particularly careful then are those > who create new feeds from existing feeds: they need to be careful > to assign appropriate values for @ns attributes rather than just > copying them thru blindly. This is not difficult; the necessary > tools exist in XSLT/XPath, f.ex. ...which not everyone is going to be using. Copying and pasting @type will be easy for everyone. >> 3) Some people are still going to do it the way it's being done >> now, leaving us with the ambiguous status of the div. Is it >> part of the content or just a container? > > Is that really a great concern? Both semantically and > presentionally, xhtml:div is neutral, so considering it > to be part of the content does not change its interpretation. > Thus, I don’t see any harm in eliding the issue altogether. This question has been discussed before, and the group is divided on it. Actually, it's not presentationally neutral. Consider the difference between these: This is the entry title This is the entry content. This is the entry title
This is the entry content.
In the first, the content is displayed inline, and thus the line doesn't break after the link. In the second, there's a linebreak. See also http://www.imc.org/atom-syntax/mail-archive/msg13535.html From owner-atom-syntax@mail.imc.org Fri Apr 15 20:38:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13309 for ; Fri, 15 Apr 2005 20:38:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3G0PLnG023668; Fri, 15 Apr 2005 17:25:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3G0PLDF023667; Fri, 15 Apr 2005 17:25:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3G0PJTY023659 for ; Fri, 15 Apr 2005 17:25:20 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 57476 messnum 2896506 invoked from network[83.70.217.193/unknown]); 16 Apr 2005 00:25:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail06.svc.cra.dublin.eircom.net (qp 57476) with SMTP; 16 Apr 2005 00:25:13 -0000 Message-ID: <42605B67.9010905@dehora.net> Date: Sat, 16 Apr 2005 01:25:11 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Klotz, Leigh" CC: atom-syntax@imc.org Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Klotz, Leigh wrote: > Bill, > Thank you for the answer. > > I'm being cautious here, because vocabulary integration is one of my main concerns in the direction Atom is taking, and I hate to see everything hard-coded with special deference to particular HTML tags. If we can't solve the problems without recourse to spec changes, we won't be building an extensible standard. > > Could you let me know why RNG can't be normative? Is it written down somewhere in the RFC? It is written down. There is consensus in the WG that the spec text be the final word. > There's normative BNF in various IETF RFCs and I don't see much difference, especially since RNC looks like BNF and it's now an ISO standard. > > I do tend to disagree on the terminology issue, still, though. > I think that saying we have an "XML-in-XML" problem leads people to think of encapsulation and semantic-blind content carrying (think base64 or CDATA), whereas calling it "mixed vocabulary" implies solutions that are at the semantic level, and I believe lead to extensibility. Extensibility so far in Atom has been firstly along the axis of particular attributes/values that applies to the format itself. Second is along the axis of adding names from other namespaces as children of the entry element making Atom a general purpose metadata container (the entry then is much like a dictionary). But while XHTML and text is an issue atm, it's worth pointing out that atom:content can carry arbitrary XML. [After some thought, I'll stand by the XML in XML thing while believing it open up a level of debate that is maybe not helpful right now.] > Dave Orchard and Dare Obasanjo have written eloquently on designing languages for for integration and extensibility [1] [2] [3]. The articles point out some obstacles in using XML Schema so I suggested RNG; although prose would work, it's more, well, wordy, and open to interpretation in the implementation. They have.The problem for us going that route is as I see it that we'll risk imposing processing constraints and coordination on producers and consumers that will be rejected in practice. [My personal view is that this speaks to modularity and not extensibility; for example things like RDF, or say Lisp, have a very notion of what an extension is. Being able to mix and match lexically and between versions is not what I think about first when it comes to extension, but I've been told that's not a common interpretation.] cheers Bill From owner-atom-syntax@mail.imc.org Sat Apr 16 14:53:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23805 for ; Sat, 16 Apr 2005 14:53:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GInPEQ034949; Sat, 16 Apr 2005 11:49:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3GInPkn034948; Sat, 16 Apr 2005 11:49:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GInOJF034942 for ; Sat, 16 Apr 2005 11:49:24 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DMsM5-0005Bx-06; Sat, 16 Apr 2005 18:49:21 +0000 Message-ID: <42615E31.50709@franklinmint.fm> Date: Sat, 16 Apr 2005 14:49:21 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: atom-syntax@imc.org Subject: atom:content (was: updated issues list for draft 07) References: <4252EAB9.6040500@gmx.de> In-Reply-To: <4252EAB9.6040500@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > Update -06: I'm still confused by the text. For instance: > > - is it intentional that 4.1.3.3 says ``If the value of "type" ends with > "+xml" or "/xml"'', while 4.1.3.2 used ``If the value of type begins > with "text/" or ends with "+xml"''? Yes. In 4.1.3.3, you're supposed to apply them in order. Is that what you find confusing? > > - also, if content for +xml SHOULD be local (4.1.3.2), why does 4.1.3.3. > point 4, make statements about situations where it comes with @src > attribute? I don't know. We should be able to strike them, right? > Maybe it's not a SHOULD requirement after all? In particular, that's a should against text/plain and text/html in @src. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Apr 16 15:07:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24298 for ; Sat, 16 Apr 2005 15:07:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GFpC2v024035; Sat, 16 Apr 2005 08:51:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3GFpCAJ024034; Sat, 16 Apr 2005 08:51:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GFpBEm024010 for ; Sat, 16 Apr 2005 08:51:12 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3GFnu32024102 for ; Sat, 16 Apr 2005 16:50:07 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: atom-syntax From: Graham Subject: How should this be rendered? Date: Sat, 16 Apr 2005 16:50:10 +0100 X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Adapted from a BBC feed I was playing with: ARCHAEOLOGY AND IMPERIALISM In 1842 a young English adventurer called Austen Henry Layard set out to excavate what he hoped were the remains of the biblical city of Nineveh in Mesopotamia. On arrival he discovered that the local French consul, Paul Emile Botta, was already hard at work. Across the Middle East and in Egypt, archaeologists, antiquarians and adventurers were exploring cities older than the Bible and shipping spectacular monuments down the Nile and the Tigris to burgeoning European museums. What was it about the ancient cultures of Egypt and Mesopotamia that so gripped the 19th century imagination? How did nationalism and imperialism affect the search for the ancient past and how did archaeology evolve from its adventuresome, even reckless, origins into the science of artefacts we know today? Contributors: Tim Champion, Professor of Archaeology at the University of Southampton, Richard Parkinson, Assistant Keeper in the Department of Ancient Egypt and Sudan at the British Museum, Eleanor Robson, Lecturer in the History and Philosophy of Science at Cambridge University and a Fellow of All Souls College, Oxford Making this MP3 available is an experiment. We value your thoughts about this trial, and would appreciate feedback at: http://www.bbc.co.uk/radio4/history/inourtime/mp3.shtml#feedback ==== Should the line breaks be shown to the user? Please quote spec text to back up your answers. Graham From owner-atom-syntax@mail.imc.org Sat Apr 16 15:09:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24390 for ; Sat, 16 Apr 2005 15:09:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GEveAj021732; Sat, 16 Apr 2005 07:57:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3GEvevG021731; Sat, 16 Apr 2005 07:57:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GEvcGM021722 for ; Sat, 16 Apr 2005 07:57:38 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl9t.cable.mindspring.com ([24.215.213.61] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DMojc-00034d-A7; Sat, 16 Apr 2005 14:57:24 +0000 Message-ID: <426127D2.3080002@franklinmint.fm> Date: Sat, 16 Apr 2005 10:57:22 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Powell CC: =?windows-1252?Q?Bill_de_h=D3ra?= , Atom Syntax , Norman Walsh Subject: Extensions containing Atom elements (was: Obs on format-07) References: <425491E7.3020605@dehora.net> <7910428092.20050407231536@djpowell.net> In-Reply-To: <7910428092.20050407231536@djpowell.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Powell wrote: > >>- in 6.4; extension schema allow the use of the atom namespace as child >>elements of the extension. I do not recall this being discussed, but >>personally am +1 to it. > > > Yeah, I'm ok with it too. I'm not sure why anyone would want to do it, > but the spirit of Structured Extension elements was that (almost) > anything goes. Sounds right to me. If I'm not mistaken, we'll need to define 'anyElement' in the RNC as follows: anyElement = element * { (attribute * { text } | text | anyElement)* } Robert Sayre From owner-atom-syntax@mail.imc.org Sat Apr 16 15:11:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24459 for ; Sat, 16 Apr 2005 15:11:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GJ3iGv035923; Sat, 16 Apr 2005 12:03:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3GJ3irE035922; Sat, 16 Apr 2005 12:03:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GJ3gXe035913 for ; Sat, 16 Apr 2005 12:03:43 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 17 Apr 2005 05:03:36 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 17 Apr 2005 05:03:37 +1000 Subject: Re: How should this be rendered? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 17/4/05 1:50 AM, "Graham" wrote: > Should the line breaks be shown to the user? Please quote spec text to > back up your answers. wouldn't that depend on what the end application is, and how it displays text/plain? my email client displays text/plain with line breaks, my various browsers do too, my hex editor doesn't. e. From owner-atom-syntax@mail.imc.org Sat Apr 16 15:37:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02269 for ; Sat, 16 Apr 2005 15:37:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GJQIDd037198; Sat, 16 Apr 2005 12:26:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3GJQI8M037197; Sat, 16 Apr 2005 12:26:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GJQH1s037183 for ; Sat, 16 Apr 2005 12:26:18 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3GJPToC025725; Sat, 16 Apr 2005 20:25:34 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6329ffdcfe698abbc9922176d0ff3458@mac.com> Content-Transfer-Encoding: 7bit Cc: "atom-syntax Syntax'" From: Graham Subject: Re: How should this be rendered? Date: Sat, 16 Apr 2005 20:25:46 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16 Apr 2005, at 8:03 pm, Eric Scheid wrote: > On 17/4/05 1:50 AM, "Graham" wrote: > >> Should the line breaks be shown to the user? Please quote spec text to >> back up your answers. > > wouldn't that depend on what the end application is, and how it > displays > text/plain? > > my email client displays text/plain with line breaks, my various > browsers do > too, my hex editor doesn't. So your saying under normal circumstances a client should display the line breaks? Seeing as I've been told before that the spec clearly says they shouldn't, I think we have a problem. Graham From owner-atom-syntax@mail.imc.org Sat Apr 16 15:41:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02788 for ; Sat, 16 Apr 2005 15:41:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GJXqHZ037577; Sat, 16 Apr 2005 12:33:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3GJXq4h037576; Sat, 16 Apr 2005 12:33:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GJXpBx037569 for ; Sat, 16 Apr 2005 12:33:51 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DMt32-0005eQ-Ra; Sat, 16 Apr 2005 19:33:44 +0000 Message-ID: <42616899.8080709@franklinmint.fm> Date: Sat, 16 Apr 2005 15:33:45 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Eric Scheid , "atom-syntax Syntax'" Subject: Re: How should this be rendered? References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> In-Reply-To: <6329ffdcfe698abbc9922176d0ff3458@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > So your saying under normal circumstances a client should display the > line breaks? Seeing as I've been told before that the spec clearly says > they shouldn't, I think we have a problem. "Atom Processors MAY display it using normal text rendering techniques such as proportional fonts, white-space collapsing, and justification." MAY or MAY NOT. There's no right answer in there right now. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Apr 16 15:58:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05218 for ; Sat, 16 Apr 2005 15:58:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GJqtlQ039276; Sat, 16 Apr 2005 12:52:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3GJqtMo039275; Sat, 16 Apr 2005 12:52:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GJqsAS039267 for ; Sat, 16 Apr 2005 12:52:54 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.56.48]) by smtp.cegetel.net (Postfix) with ESMTP id 69C716747E; Sat, 16 Apr 2005 21:52:48 +0200 (CEST) Message-ID: <42616D17.3060300@cegetel.net> Date: Sat, 16 Apr 2005 21:52:56 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Robert Sayre Cc: Julian Reschke , atom-syntax@imc.org Subject: Re: atom:content References: <4252EAB9.6040500@gmx.de> <42615E31.50709@franklinmint.fm> In-Reply-To: <42615E31.50709@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Julian Reschke wrote: >> - is it intentional that 4.1.3.3 says ``If the value of "type" ends >> with "+xml" or "/xml"'', This means the element content is some kind of XML: text/xml, application/xml and any "+xml" type. However, it excludes {text,application}/xml-external-parsed-entity. Maybe the wording should be « If the value of "type" is a MIME media type whose subtype begins with "xml" or ends with "+xml" » >> while 4.1.3.2 used ``If the value of type begins with "text/" or >> ends with "+xml"''? This means the element content is some kind of "text- or xml-based content": text/plain, text/xml and any "+xml" type (image/svg+xml, application/xhtml+xml, etc.). However it excludes application/xml, as well as application/xml-external-parsed-entity. Maybe the wording should be « If the value of type is a MIME media type whose type is "text" or whose subtype begins with "xml" or ends with "+xml" ». Although it depends what's the wanted meaning of the statement: should XML-based contents be provided inline when they are some kind of "human readable text content" (falls in the text/xml "group" as defined in [RFC3023], section 3. XML Media Types), or when they are "text-based" and can therefor be included without further "encoding" (other than "charset recoding" when necessary), which also includes "computer-only content" such as MathML, SVG, CSV, etc. ? Moreover, the SHOULD in this section might be too strong: if you include XML content, you loose DTD (thus validity) and, more important, entity definitions (such as   and others). Please note that in the two previous wording proposals, « subtype begins with "xml" » might be restricted to « subtype is "xml" or "xml-external-parsed-entity" ». Robert Sayre wrote: > Yes. In 4.1.3.3, you're supposed to apply them in order. Is that what > you find confusing? I don't think Julian talked about it but, yes it's quite confusing... Julian Reschke wrote: >> - also, if content for +xml SHOULD be local (4.1.3.2), why does >> 4.1.3.3. point 4, make statements about situations where it comes >> with @src attribute? Because in 4.1.3.2 it was a SHOULD, not a MUST, so XML content MAY be provided "outline". [RFC3023] http://www.ietf.org/rfc/rfc3023.txt -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sat Apr 16 16:10:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06863 for ; Sat, 16 Apr 2005 16:10:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GI8Xpn031914; Sat, 16 Apr 2005 11:08:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3GI8XI4031913; Sat, 16 Apr 2005 11:08:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GI8WdV031904 for ; Sat, 16 Apr 2005 11:08:32 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc14) with SMTP id <20050416180827014005o33ue>; Sat, 16 Apr 2005 18:08:27 +0000 Date: Sat, 16 Apr 2005 12:08:25 -0600 Subject: Re: Trade mandatory xhtml:div for atom:content/@container? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <42603CF4.2020309@cegetel.net> Message-Id: <87223877-AEA2-11D9-BBD2-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, April 15, 2005, at 04:15 PM, Thomas Broyer wrote: > Antone Roundy wrote: >> Could we drop the xhtml:div requirement in content[@type="xhtml"], > +1 >> and instead clarify the status of the div that is commonly being put >> there (is it part of the content or not?) > +1 >> by adding an attribute to atom:content > -1 ... > With @type="text" there is no container, neither with @type="html", so > why should there be a container with @type="xhtml"? Because it's XML in XML, which raises issues that don't exist for "text" and "html". Some people prefer to switch default namespace when doing XML in XML. If the XHTML content they're putting into atom:content isn't already surrounded by a single element where that switch can be made, adding a container to hold the namespace declaration is a common way of doing it. > Just for carrying the xmlns declaration? Well, you'd better define it > once in the feed element... You can argue that that's a better method, but we have already discussed and rejected the idea of mandating that the namespace be declared in a particular place or a particular way. > Just to allow for prefix-free Atom documents? See below about "legacy > Atom" documents. > > So what about those existing Atom documents (0.3 or > draft-ietf-atompub-format-07) using a div container? Well, keep them > as they are! > What's the matter with having the entry content inside an XHTML div, > itself being considered part of the content? > A div element in (X)HTML has only a structural meaning. If the entry > content is to be rendered as part of an XHTML document (as in a Web > aggregator, or in a blog for example when Atom is used as a publishing > protocol/syntax) and included inside a div element, the duplicate divs > won't change anything to the document structure, there'll just be a > needless duplicate div... See http://www.imc.org/atom-syntax/mail-archive/msg14238.html for my response. I don't think we're going to oust the required container div unless we replace it with something. Between the options of having a required container div and having an optional attribute to indicate whether you're using a container div, which would you prefer? From owner-atom-syntax@mail.imc.org Sat Apr 16 19:03:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16877 for ; Sat, 16 Apr 2005 19:03:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GMsAoi050643; Sat, 16 Apr 2005 15:54:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3GMsARj050642; Sat, 16 Apr 2005 15:54:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GMs80s050631 for ; Sat, 16 Apr 2005 15:54:09 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.56.48]) by smtp.cegetel.net (Postfix) with ESMTP id ED33267274; Sun, 17 Apr 2005 00:54:02 +0200 (CEST) Message-ID: <42619794.9000701@cegetel.net> Date: Sun, 17 Apr 2005 00:54:12 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: Trade mandatory xhtml:div for atom:content/@container? References: <87223877-AEA2-11D9-BBD2-003065EA6144@geckotribe.com> In-Reply-To: <87223877-AEA2-11D9-BBD2-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: >> With @type="text" there is no container, neither with @type="html", >> so why should there be a container with @type="xhtml"? > > Because it's XML in XML, which raises issues that don't exist for > "text" and "html". Yes, but it's still "content". > Some people prefer to switch default namespace when doing XML in XML. > If the XHTML content they're putting into atom:content isn't already > surrounded by a single element where that switch can be made, adding > a container to hold the namespace declaration is a common way of > doing it. ...so they can use meaningless divs or spans containers, depending whether they have block or inline content. And some people prefer having a clean, needless-container-free feed, using prefixes and declaring namespaces in the enclosing element (or any of its ancestors). >> Just for carrying the xmlns declaration? Well, you'd better define >> it once in the feed element... > > You can argue that that's a better method, but we have already > discussed and rejected the idea of mandating that the namespace be > declared in a particular place or a particular way. I'm not trying to mandate anything! And you're right: I'm just arguing that that's a better method. >> What's the matter with having the entry content inside an XHTML >> div, itself being considered part of the content? A div element in >> (X)HTML has only a structural meaning. If the entry content is to >> be rendered as part of an XHTML document (as in a Web aggregator, >> or in a blog for example when Atom is used as a publishing >> protocol/syntax) and included inside a div element, the duplicate >> divs won't change anything to the document structure, there'll just >> be a needless duplicate div... > > > See http://www.imc.org/atom-syntax/mail-archive/msg14238.html for my > response. And putting a title in a div, therefore allowing paragraphs in it, does not disturb you? > I don't think we're going to oust the required container div unless > we replace it with something. Between the options of having a > required container div and having an optional attribute to indicate > whether you're using a container div, which would you prefer? The third option: using a "div" container when I want block- and "span" when I want inline-content. However, I personally actually prefer using an "atom" prefix for Atom elements and no prefix for XHTML... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sat Apr 16 19:08:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17049 for ; Sat, 16 Apr 2005 19:08:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3GMxh41051282; Sat, 16 Apr 2005 15:59:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3GMxh3Z051281; Sat, 16 Apr 2005 15:59:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3GMxfhf051270 for ; Sat, 16 Apr 2005 15:59:42 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 16 Apr 2005 22:59:35 -0000 Received: from xdsl-213-196-248-153.netcologne.de (EHLO klangraum) [213.196.248.153] by mail.gmx.net (mp018) with SMTP; 17 Apr 2005 00:59:35 +0200 X-Authenticated: #163624 Date: Sun, 17 Apr 2005 01:02:26 +0200 From: "A. Pagaltzis" To: "atom-syntax Syntax'" Subject: Re: How should this be rendered? Message-ID: <20050416230226.GA1894@klangraum> Mail-Followup-To: atom-syntax Syntax' References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <42616899.8080709@franklinmint.fm> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Robert Sayre [2005-04-16 21:45]: > "Atom Processors MAY display it using normal text rendering > techniques such as proportional fonts, white-space collapsing, > and justification." > > MAY or MAY NOT. There's no right answer in there right now. Would @xml:space be applicable if I as a producer want to be certain of a way of interpreting my content? Say, because I’m putting ASCII art in there? Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Sun Apr 17 04:56:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04015 for ; Sun, 17 Apr 2005 04:56:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3H8mAms061908; Sun, 17 Apr 2005 01:48:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3H8mAQM061907; Sun, 17 Apr 2005 01:48:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3H8m95K061890 for ; Sun, 17 Apr 2005 01:48:09 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:50050 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228716AbVDQIsH convert rfc822-to-8bit (ORCPT ); Sun, 17 Apr 2005 11:48:07 +0300 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <425EBF72.2090508@franklinmint.fm> References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425D5F91.9040809@annevankesteren.nl> <425E5C50.9090301@dehora.net> <425EBF72.2090508@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <4778ea783270352e9b73114db9da4fd4@iki.fi> Content-Transfer-Encoding: 8BIT From: Henri Sivonen Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments Date: Sun, 17 Apr 2005 11:47:39 +0300 To: "Atom-Syntax Syntax'" X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Apr 14, 2005, at 22:07, Robert Sayre wrote: > Bill de hÓra wrote: > >> If there is not a tidy way out of this, or we don't just agree to >> scope it as a point solution for a particular flavour of XHTML, I >> suggest we revisit the xhtml:div approach altogether. > > Bill, I don't think the problem is exclusive to the outer div. I can't > find any version of XHTML that allows where xh is bound to the > XHTML namespace URI. DTDs and namespaces are inherently incompatible. I think the restrictions the official DTDs place on namespace declarations should be ignored when embedding XHTML in Atom. (Note that the XHTML Modularization DTDs have stuff that can be parametrized.) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Sun Apr 17 06:05:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07700 for ; Sun, 17 Apr 2005 06:05:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3H9s8sV084082; Sun, 17 Apr 2005 02:54:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3H9s82U084080; Sun, 17 Apr 2005 02:54:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3H9s6K9084030 for ; Sun, 17 Apr 2005 02:54:07 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050417095400.HKAU10257.mta08-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Sun, 17 Apr 2005 10:54:00 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050417095400.HYAB1844.aamta08-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com>; Sun, 17 Apr 2005 10:54:00 +0100 Date: Sun, 17 Apr 2005 10:53:57 +0100 From: David Powell X-Mailer: The Bat! (v3.0.9.15 Return) Professional X-Priority: 3 (Normal) Message-ID: <1812713729.20050417105357@djpowell.net> To: Henri Sivonen CC: "Atom-Syntax Syntax'" Subject: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments In-Reply-To: <4778ea783270352e9b73114db9da4fd4@iki.fi> References: <42579382.3040003@gmx.de> <6.0.0.20.2.20050409202455.06e0d7f0@itmail.it.aoyama.ac.jp> <87k6n9rub9.fsf@nwalsh.com> <425AD3EE.5070701@annevankesteren.nl> <87ekdhqd7w.fsf@nwalsh.com> <425D5F91.9040809@annevankesteren.nl> <425E5C50.9090301@dehora.net> <425EBF72.2090508@franklinmint.fm> <4778ea783270352e9b73114db9da4fd4@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sunday, April 17, 2005, 9:47:39 AM, Henri Sivonen wrote: > DTDs and namespaces are inherently incompatible. I think the > restrictions the official DTDs place on namespace declarations should > be ignored when embedding XHTML in Atom. I strongly agree. Namespaces are a pretty fragile technology; any solution that requires micro-management of namespace declarations is going to be even more fragile. As far as I know, XSLT and many XML APIs don't have any control over the position of namespace declarations. We shouldn't be forcing publishers to use printf to generate Atom. -- Dave From owner-atom-syntax@mail.imc.org Sun Apr 17 12:24:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03057 for ; Sun, 17 Apr 2005 12:24:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3HGGBgJ058416; Sun, 17 Apr 2005 09:16:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3HGGBkN058415; Sun, 17 Apr 2005 09:16:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3HGG98N058402 for ; Sun, 17 Apr 2005 09:16:10 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.57.139]) by smtp.cegetel.net (Postfix) with ESMTP id BF908674F4; Sun, 17 Apr 2005 18:16:03 +0200 (CEST) Message-ID: <42628BCB.9080407@cegetel.net> Date: Sun, 17 Apr 2005 18:16:11 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... References: <11E25F3D-AD20-11D9-9590-003065EA6144@geckotribe.com> In-Reply-To: <11E25F3D-AD20-11D9-9590-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ...only about subsets/supersets and duplicates... Antone Roundy wrote: > @rel="subset-of" @rel="superset"? > We've already got a way to handle aggregations from multiple sources. > Do we want to allow people to choose to just use a "secondary-to" > link to express that relationship rather than atom:source-feed with > it's copy of the feed metadata? atom:source must not contain a copy of the whole original feed's metadata, only the metadata required in atom:feed are (should be?) required in atom:source. (Yes, I know I previously said the whole metadata should be copied, I now think it was a mistake: copy only what you want to copy, as long as you copy the minimum required metadata) > Strict subsets on the other hand might have very different feed level > metadata, which would make using atom:source-feed to express them as > aggregations (even though they're from a single source) more > technically accurate. But since each entry would have to have an > identical copy of atom:source-feed in that case, it would be a little > sloppy. Might we add an "internal reference" system? ... ... ... Problems: - if we allow this for atom:source, we might as well allow it for person constructs (e.g. all entry authors are listed in the feed's contributors and referenced by entries atom:author or contributors; this prevents duplication of person constructs describing the same constructs) - this is a big enhancement to the spec and won't do it for Atom 1.0 An alternative would be to use a link element with @rel="superset" telling aggregators that the entries in this feeds are copies of entries in the linked feed. Entries with the same atom:id would then be considered duplicates and only the "superset" feed would have "authority": if an entry is said to have been updated in the subset feed but not in the superset feed, it might be an "attack", so ignore it. Same if an entry has been added to the subset feed without appearing in the superset feed (problem: an entry could "disappear" from the superset feed due to many newer entries "pushing the entry towards the exit"). Actually, if both the superset and subset feeds are used in aggregations, the subset feed would only be used to list the entries (from the superset feed) which compose the subset. Such a link MUST then be copied in an atom:source element when the subset feed is used in aggregations... and this obviously complicates the aggregation process: some links MUST be copied, others only SHOULD or MAY, depending on their @rel value... To simplify this process, the solution would be that link @rel="superset" doesn't prevent you from using atom:source, which brings us back to the beginning... A feed might also lists its subsets (e.g. category feeds) using link elements with @rel="subset", though this list would only be informative, without the aggregating rules above (preventing from "attacks": I create a feed that declares another feed as a subset in order for my entries to take precedence over the "real feed" entries). Conclusion: all this should IMHO be delayed until the next Atom version... People will probably create extension elements and time will tell us about their advantages and drawbacks, then the Atom WG would be able to choose what to include in the Atom spec. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sun Apr 17 17:23:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23298 for ; Sun, 17 Apr 2005 17:23:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3HLFgU4089544; Sun, 17 Apr 2005 14:15:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3HLFgFW089543; Sun, 17 Apr 2005 14:15:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3HLFeS3089507 for ; Sun, 17 Apr 2005 14:15:41 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050417211534.JZEG2375.mta13-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com> for ; Sun, 17 Apr 2005 22:15:34 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050417211534.EKLJ1844.aamta08-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com> for ; Sun, 17 Apr 2005 22:15:34 +0100 Date: Sun, 17 Apr 2005 22:15:31 +0100 From: David Powell X-Mailer: The Bat! (v3.0.9.15 Return) Professional X-Priority: 3 (Normal) Message-ID: <862484404.20050417221531@djpowell.net> CC: Atom Syntax Subject: Re: atom:source interactions with xml:base/xml:lang In-Reply-To: <496491534.20050408000245@djpowell.net> References: <496491534.20050408000245@djpowell.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I've posted a draft of PaceSourceRecs [1]. It proposes that an informative section should be added to give some recommendations on how to use safely use atom:source without screwing up xml:lang and xml:base. I'm not sure where the Informative section should go? Should it go inline, as a sub-section of the description of atom:source, should it go in a top-level section near the end, or does it belong in an appendix? Sorry about it being a bit rough around the edges, but I thought I'd post it anyway to get some feedback. [1] http://www.intertwingly.net/wiki/pie/PaceSourceRecs -- Dave From owner-atom-syntax@mail.imc.org Mon Apr 18 12:53:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05690 for ; Mon, 18 Apr 2005 12:53:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IGcBhk086252; Mon, 18 Apr 2005 09:38:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IGcBdR086251; Mon, 18 Apr 2005 09:38:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3IGc8hK086218 for ; Mon, 18 Apr 2005 09:38:09 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 18 Apr 2005 16:38:01 -0000 Received: from p508F8B6A.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [80.143.139.106] by mail.gmx.net (mp028) with SMTP; 18 Apr 2005 18:38:01 +0200 X-Authenticated: #1915285 Message-ID: <4263E266.3030402@gmx.de> Date: Mon, 18 Apr 2005 18:37:58 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: atom:content References: <4252EAB9.6040500@gmx.de> <42615E31.50709@franklinmint.fm> In-Reply-To: <42615E31.50709@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > Julian Reschke wrote: > > >> Update -06: I'm still confused by the text. For instance: >> >> - is it intentional that 4.1.3.3 says ``If the value of "type" ends >> with "+xml" or "/xml"'', while 4.1.3.2 used ``If the value of type >> begins with "text/" or ends with "+xml"''? > > > Yes. In 4.1.3.3, you're supposed to apply them in order. Is that what > you find confusing? Actually, this is what I didn't notice. My fault. >> - also, if content for +xml SHOULD be local (4.1.3.2), why does >> 4.1.3.3. point 4, make statements about situations where it comes with >> @src attribute? > > > I don't know. We should be able to strike them, right? Yes. Either it's a SHOULD level requirement that the content is in-line (in which case we shouldn't say anything about the other case), or IMHO it's not a SHOULD after all. >> Maybe it's not a SHOULD requirement after all? > > > In particular, that's a should against text/plain and text/html in @src. Hm, I didn't get that. Right now it says (): "If the value of type begins with "text/" or ends with "+xml", the content SHOULD be local; that is to say, no "src" attribute should be provided." Are you saying that the requirements are different for (i) "text/" and (ii) for "/...+xml"? Best regards, Julian From owner-atom-syntax@mail.imc.org Mon Apr 18 13:47:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10202 for ; Mon, 18 Apr 2005 13:47:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IHTaXS093084; Mon, 18 Apr 2005 10:29:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IHTaAQ093083; Mon, 18 Apr 2005 10:29:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IHTZ3p093076 for ; Mon, 18 Apr 2005 10:29:35 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.3]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DNa3v-0001Hq-6t; Mon, 18 Apr 2005 17:29:31 +0000 Message-ID: <4263EE7A.3090400@franklinmint.fm> Date: Mon, 18 Apr 2005 13:29:30 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: atom-syntax@imc.org Subject: Re: atom:content References: <4252EAB9.6040500@gmx.de> <42615E31.50709@franklinmint.fm> <4263E266.3030402@gmx.de> In-Reply-To: <4263E266.3030402@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: >>> - also, if content for +xml SHOULD be local (4.1.3.2), why does >>> 4.1.3.3. point 4, make statements about situations where it comes >>> with @src attribute? >> >> >> >> I don't know. We should be able to strike them, right? > > > Yes. Either it's a SHOULD level requirement that the content is in-line > (in which case we shouldn't say anything about the other case), or IMHO > it's not a SHOULD after all. Fair enough. >>> Maybe it's not a SHOULD requirement after all? >> >> >> >> In particular, that's a should against text/plain and text/html in @src. > > > Hm, I didn't get that. Right now it says > (): > > > "If the value of type begins with "text/" or ends with "+xml", the > content SHOULD be local; that is to say, no "src" attribute should be > provided." > > Are you saying that the requirements are different for (i) "text/" and > (ii) for "/...+xml"? Yes, because it isn't base64 or escaped, you can't put text/plain or text/html inline. So, you have to use @src, but you SHOULD NOT. The fact that every MIME type under the sun can't be accomodated isn't a serious flaw, though. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Apr 18 13:47:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10236 for ; Mon, 18 Apr 2005 13:47:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IHYSNi093954; Mon, 18 Apr 2005 10:34:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IHYSmp093953; Mon, 18 Apr 2005 10:34:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IHYSnn093947 for ; Mon, 18 Apr 2005 10:34:28 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-2 ([129.148.9.73]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j3IHYRjG014024 for ; Mon, 18 Apr 2005 10:34:28 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IF500101KPGYO@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Mon, 18 Apr 2005 13:34:27 -0400 (EDT) Received: from localhost (vpn-129-150-34-110.Central.Sun.COM [129.150.34.110]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IF5009TXKTEXD@bur-mail1.east.sun.com> for atom-syntax@imc.org; Mon, 18 Apr 2005 13:34:27 -0400 (EDT) Received: from ndw by localhost with local (Exim 4.50) id 1DNa8s-0000MA-HH for atom-syntax@imc.org; Mon, 18 Apr 2005 13:34:38 -0400 X-URL: http://nwalsh.com/ Date: Mon, 18 Apr 2005 13:34:33 -0400 From: Norman Walsh Subject: Re: Extensions containing Atom elements In-reply-to: <426127D2.3080002@franklinmint.fm> To: atom-syntax@imc.org Message-id: <87acnwgf9y.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) References: <425491E7.3020605@dehora.net> <7910428092.20050407231536@djpowell.net> <426127D2.3080002@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Robert Sayre was heard to say: | David Powell wrote: |> |>>- in 6.4; extension schema allow the use of the atom namespace as child |>>elements of the extension. I do not recall this being discussed, but |>>personally am +1 to it. |> Yeah, I'm ok with it too. I'm not sure why anyone would want to do |> it, |> but the spirit of Structured Extension elements was that (almost) |> anything goes. | | Sounds right to me. If I'm not mistaken, we'll need to define | 'anyElement' in the RNC as follows: | | anyElement =3D | element * { | (attribute * { text } | | text | | anyElement)* | } It might be a little trickier than that. If you do that, then by atomInlineOtherContent =3D element atom:content { atomCommonAttributes, attribute type { atomMediaType }?, (text|anyElement)* } it'll be valid to write: ... which we probably don't want to allow :-) The point is that extensions should allow atom:content inside the extension, is that right? Be seeing you, norm =2D-=20 Norman Walsh | Everything should be made as simple as http://nwalsh.com/ | possible, but no simpler. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCY++pOyltUcwYWjsRAgRCAJ41YNR/FcdgO3lq0P3/mbiLVFPlZgCeJD/f kCHp3Gn772EwHyQlFeIoUHw= =UGMf -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Mon Apr 18 13:49:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10408 for ; Mon, 18 Apr 2005 13:49:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IHgNHr095437; Mon, 18 Apr 2005 10:42:23 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IHgNEu095436; Mon, 18 Apr 2005 10:42:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IHgNkT095424 for ; Mon, 18 Apr 2005 10:42:23 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.3]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DNaGH-0001OA-4C; Mon, 18 Apr 2005 17:42:17 +0000 Message-ID: <4263F17A.7040009@franklinmint.fm> Date: Mon, 18 Apr 2005 13:42:18 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Walsh CC: atom-syntax@imc.org Subject: Re: Extensions containing Atom elements References: <425491E7.3020605@dehora.net> <7910428092.20050407231536@djpowell.net> <426127D2.3080002@franklinmint.fm> <87acnwgf9y.fsf@nwalsh.com> In-Reply-To: <87acnwgf9y.fsf@nwalsh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > The point is that extensions should allow atom:content inside the > extension, is that right? Yes. Any atom element should be allowed in an extension. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Apr 18 13:59:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11355 for ; Mon, 18 Apr 2005 13:59:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IHrHXc097690; Mon, 18 Apr 2005 10:53:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IHrHrH097687; Mon, 18 Apr 2005 10:53:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IHrGQ8097651 for ; Mon, 18 Apr 2005 10:53:16 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3IHq4xN025537; Mon, 18 Apr 2005 18:52:15 +0100 (BST) In-Reply-To: <20050416230226.GA1894@klangraum> References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> <20050416230226.GA1894@klangraum> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Cc: "atom-syntax Syntax'" From: Graham Subject: Re: How should this be rendered? Date: Mon, 18 Apr 2005 18:52:05 +0100 To: "A. Pagaltzis" X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3IHrHQ8097682 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 17 Apr 2005, at 12:02 am, A. Pagaltzis wrote: > * Robert Sayre [2005-04-16 21:45]: >> "Atom Processors MAY display it using normal text rendering >> techniques such as proportional fonts, white-space collapsing, >> and justification." >> >> MAY or MAY NOT. There's no right answer in there right now. > > Would @xml:space be applicable if I as a producer want to be > certain of a way of interpreting my content? Say, because I’m > putting ASCII art in there? No, since xml:space isn't a built-in part of XML, and isn't referenced by the atom spec. It can only be used when spec-makers (us) say it can. Graham Parks From owner-atom-syntax@mail.imc.org Mon Apr 18 14:10:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12587 for ; Mon, 18 Apr 2005 14:10:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3II1HoA099072; Mon, 18 Apr 2005 11:01:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3II1HKe099071; Mon, 18 Apr 2005 11:01:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3II1Ggd099041 for ; Mon, 18 Apr 2005 11:01:16 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3II0dj8027915; Mon, 18 Apr 2005 19:00:39 +0100 (BST) In-Reply-To: <42616899.8080709@franklinmint.fm> References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <36b15b1135c025234f12d1646a216f6f@mac.com> Content-Transfer-Encoding: 7bit Cc: "atom-syntax Syntax'" From: Graham Subject: Re: How should this be rendered? Date: Mon, 18 Apr 2005 19:00:40 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16 Apr 2005, at 8:33 pm, Robert Sayre wrote: > MAY or MAY NOT. There's no right answer in there right now. I'm OK with line-breaks being ignored, because it means documents where the XML has been wrapped to 80 columns aren't messed up. I'm not OK with publishers not being clear on the situation. Would anyone object to "(including line-breaks)" being added after "white-space collapsing": "Atom Processors MAY display it using normal text rendering techniques such as proportional fonts, white-space collapsing, and justification." I'd also like to remove the word "normal" from there, since these aren't normal for text/plain, which is the obvious analogy. Graham From owner-atom-syntax@mail.imc.org Mon Apr 18 14:10:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12634 for ; Mon, 18 Apr 2005 14:10:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3II1IvE099081; Mon, 18 Apr 2005 11:01:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3II1Ij3099080; Mon, 18 Apr 2005 11:01:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3II1HQQ099063 for ; Mon, 18 Apr 2005 11:01:17 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.3]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DNaYZ-0001gq-LW; Mon, 18 Apr 2005 18:01:11 +0000 Message-ID: <4263F5E9.1080501@franklinmint.fm> Date: Mon, 18 Apr 2005 14:01:13 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: "A. Pagaltzis" , "atom-syntax Syntax'" Subject: Re: How should this be rendered? References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> <20050416230226.GA1894@klangraum> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Graham wrote: > > On 17 Apr 2005, at 12:02 am, A. Pagaltzis wrote: > >> * Robert Sayre [2005-04-16 21:45]: >> >>> "Atom Processors MAY display it using normal text rendering >>> techniques such as proportional fonts, white-space collapsing, >>> and justification." >>> >>> MAY or MAY NOT. There's no right answer in there right now. >> >> >> Would @xml:space be applicable if I as a producer want to be >> certain of a way of interpreting my content? Say, because I’m >> putting ASCII art in there? > > > No, since xml:space isn't a built-in part of XML, and isn't referenced > by the atom spec. It can only be used when spec-makers (us) say it can. People can put it in there, per section 6.4, but no one has to pay attention. Let's examine our rules for HTML content. There's no requirement to use the markup to display the content, so it would be perfectly cool to drop a
. Is there a specific outcome you're looking for here? Robert Sayre From owner-atom-syntax@mail.imc.org Mon Apr 18 14:21:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13841 for ; Mon, 18 Apr 2005 14:21:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3II8ahg000306; Mon, 18 Apr 2005 11:08:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3II8a1S000305; Mon, 18 Apr 2005 11:08:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3II8Z0B000283 for ; Mon, 18 Apr 2005 11:08:35 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.34.138]) by smtp.cegetel.net (Postfix) with ESMTP id B8291318176; Mon, 18 Apr 2005 20:08:29 +0200 (CEST) Message-ID: <4263F79E.9050203@cegetel.net> Date: Mon, 18 Apr 2005 20:08:30 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Graham Cc: "A. Pagaltzis" , "atom-syntax Syntax'" Subject: Re: How should this be rendered? References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> <20050416230226.GA1894@klangraum> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > No, since xml:space isn't a built-in part of XML, Duh! Why then is it described in http://www.w3.org/TR/2004/REC-xml-20040204/#sec-white-space > and isn't referenced > by the atom spec. It can only be used when spec-makers (us) say it can. ...and I think it should be allowed on text constructs and atom:content. How are you supposed to write an HTML PRE (or any element using the CSS "white-space" property) if the Atom processor collapses whitespace? Hello World! in C#:

class Main {
     static public void main() {
         System.Console.WriteLine("Hello World!");
     }
}
]]> -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon Apr 18 14:23:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13952 for ; Mon, 18 Apr 2005 14:23:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IIDMCg001390; Mon, 18 Apr 2005 11:13:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IIDMEE001389; Mon, 18 Apr 2005 11:13:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IIDL8S001375 for ; Mon, 18 Apr 2005 11:13:21 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 26017 invoked by uid 10); 18 Apr 2005 18:13:14 -0000 Received: (vexira-qq 26005-6698F8A9 invoked from network) 18 Apr 2005 20:13:14 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 18 Apr 2005 18:13:14 -0000 Message-ID: <4263F8BA.5010500@annevankesteren.nl> Date: Mon, 18 Apr 2005 20:13:14 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Broyer CC: Graham , "A. Pagaltzis" , "atom-syntax Syntax'" Subject: Re: How should this be rendered? References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> <20050416230226.GA1894@klangraum> <4263F79E.9050203@cegetel.net> In-Reply-To: <4263F79E.9050203@cegetel.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thomas Broyer wrote: > (or any element using the CSS "white-space" property) That is purely for presentation. You should not use it if you need whitespace to be preserverd for semantics. (In such cases xml:space would probably be more appropriate...) -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon Apr 18 14:28:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14320 for ; Mon, 18 Apr 2005 14:28:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IIKFN2002286; Mon, 18 Apr 2005 11:20:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IIKFRr002285; Mon, 18 Apr 2005 11:20:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IIKEPP002262 for ; Mon, 18 Apr 2005 11:20:14 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3IIJWQv004061; Mon, 18 Apr 2005 19:19:40 +0100 (BST) In-Reply-To: <4263F79E.9050203@cegetel.net> References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> <20050416230226.GA1894@klangraum> <4263F79E.9050203@cegetel.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: How should this be rendered? Date: Mon, 18 Apr 2005 19:19:33 +0100 To: Thomas Broyer X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 18 Apr 2005, at 7:08 pm, Thomas Broyer wrote: > Duh! Why then is it described in > http://www.w3.org/TR/2004/REC-xml-20040204/#sec-white-space It may be described there, but it doesn't do anything unless the vocabulary on top of HTML says it does. > How are you supposed to write an HTML PRE (or any element using the > CSS "white-space" property) if the Atom processor collapses > whitespace? The atom spec only references whitespace-collapsing in regards to type="text". It doesn't affect HTML. Graham Parks From owner-atom-syntax@mail.imc.org Mon Apr 18 15:17:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20404 for ; Mon, 18 Apr 2005 15:17:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IJ9AC3011649; Mon, 18 Apr 2005 12:09:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IJ9AYX011648; Mon, 18 Apr 2005 12:09:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IJ995X011635 for ; Mon, 18 Apr 2005 12:09:09 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3IJ99i7024715 for ; Mon, 18 Apr 2005 13:09:09 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IF5000Z6P79SE@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 18 Apr 2005 13:09:09 -0600 (MDT) Received: from [129.155.46.29] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IF5005LHP78UN@mail.sun.net> for atom-syntax@imc.org; Mon, 18 Apr 2005 13:09:08 -0600 (MDT) Date: Mon, 18 Apr 2005 12:09:52 -0700 From: Tim Bray Subject: Re: How should this be rendered? In-reply-to: <36b15b1135c025234f12d1646a216f6f@mac.com> To: Graham Cc: Robert Sayre , "atom-syntax Syntax'" Message-id: <41c49189775fd3d85b6f76cf99917b2d@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> <36b15b1135c025234f12d1646a216f6f@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 18, 2005, at 11:00 AM, Graham wrote: > I'm not OK with publishers not being clear on the situation. Would > anyone object to "(including line-breaks)" being added after > "white-space collapsing": Yes, I think this would be helpful. It's obvious to hacks like us that line breaks are white-space, but possibly not to everyone. > "Atom Processors MAY display it using normal text rendering techniques > such as proportional fonts, white-space collapsing, and > justification." > > I'd also like to remove the word "normal" from there, since these > aren't normal for text/plain, which is the obvious analogy. OK by me. -Tim From owner-atom-syntax@mail.imc.org Mon Apr 18 15:35:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22019 for ; Mon, 18 Apr 2005 15:35:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IJT24H016792; Mon, 18 Apr 2005 12:29:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IJT2uX016791; Mon, 18 Apr 2005 12:29:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IJT1FY016761 for ; Mon, 18 Apr 2005 12:29:01 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.34.138]) by smtp.cegetel.net (Postfix) with ESMTP id 0DC5E22C1FE; Mon, 18 Apr 2005 21:28:55 +0200 (CEST) Message-ID: <42640A7A.8090604@cegetel.net> Date: Mon, 18 Apr 2005 21:28:58 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Anne van Kesteren Cc: Graham , "A. Pagaltzis" , "atom-syntax Syntax'" Subject: Re: How should this be rendered? References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> <20050416230226.GA1894@klangraum> <4263F79E.9050203@cegetel.net> <4263F8BA.5010500@annevankesteren.nl> In-Reply-To: <4263F8BA.5010500@annevankesteren.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > Thomas Broyer wrote: >> (or any element using the CSS "white-space" property) > > > That is purely for presentation. You should not use it if you need > whitespace to be preserverd for semantics. (In such cases xml:space > would probably be more appropriate...) Right, but xml:space is applied to the XHTML "pre" element only when using a DTD (if not explicitly "instanciated" on the element, which is most likely not the case!).

Hello World! in C#:

class Main {
     static public void main() {
         System.Console.WriteLine("Hello World!");
     }
}
Atom doesn't say how whitespace should be handled inside HTML or XHTML content (text constructs or atom:content), nor inside extension elements. Graham wrote: > On 18 Apr 2005, at 7:08 pm, Thomas Broyer wrote: >> Duh! Why then is it described in >> http://www.w3.org/TR/2004/REC-xml-20040204/#sec-white-space > > It may be described there, but it doesn't do anything unless the > vocabulary on top of HTML says it does. It *does* something: it can force the application to preserve whitespace. The XML vocabulary defines where it applies, and XHTML applies it on several elements, including "pre". >> How are you supposed to write an HTML PRE (or any element using the >> CSS "white-space" property) if the Atom processor collapses >> whitespace? > > The atom spec only references whitespace-collapsing in regards to > type="text". It doesn't affect HTML. But, as said above, it doesn't define the behavior for type="html" and type="xhtml", which means the Atom processor might collapse whitespace anywhere (including XHTML "pre" element and escaped-HTML content). My feeling is that whitespace should be preserved (not collapsed) in content that will probably be passed to a secondary processor, that is XHTML and HTML, and other inline content in atom:content. As all whitespace characters are passed from the XML processor to the Atom processor, at least the spec should inform implementors that whitespace SHOULD (at least, maybe MUST) be preserved (as it may be significant) if the content is not processed by the Atom processor (e.g. "direct output" inside an (X)HTML document in the case of a Web-based aggregator, or given as input to a third-party application/library). Moreover, xml:space should be allowed on text constructs and atom:content (at least when type="text") with a default value (default to xml:space="default" for type="text") to allow content like: ... RELAX NG book at O'Reilly ... RELAX NG covers the following topics in depth: - Introduction to RELAX NG - Building RELAX NG schemas using XML syntax - Building RELAX NG schemas using compact syntax, an alternative non-XML syntax ... As extension elements are processed by the Atom processor and all whitespace is passed from the XML processor to the Atom processor, there's no need to define anything in the spec: Atom processors are responsible for handling extensions, thus whitespace collapsing/preserving of extension elements' content. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Mon Apr 18 15:52:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24461 for ; Mon, 18 Apr 2005 15:52:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IJjvE8019444; Mon, 18 Apr 2005 12:45:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IJjvxJ019443; Mon, 18 Apr 2005 12:45:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IJjvRE019436 for ; Mon, 18 Apr 2005 12:45:57 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-2 ([129.148.9.73]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3IJjujO006367 for ; Mon, 18 Apr 2005 13:45:56 -0600 (MDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IF500E01QVDRL@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Mon, 18 Apr 2005 15:45:56 -0400 (EDT) Received: from localhost (vpn-129-150-32-107.Central.Sun.COM [129.150.32.107]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IF500GQ8QWJLS@bur-mail1.east.sun.com> for atom-syntax@imc.org; Mon, 18 Apr 2005 15:45:56 -0400 (EDT) Received: from ndw by localhost with local (Exim 4.50) id 1DNcC7-0002TT-8P for atom-syntax@imc.org; Mon, 18 Apr 2005 15:46:07 -0400 X-URL: http://nwalsh.com/ Date: Mon, 18 Apr 2005 15:46:07 -0400 From: Norman Walsh Subject: Re: How should this be rendered? In-reply-to: <36b15b1135c025234f12d1646a216f6f@mac.com> To: atom-syntax@imc.org Message-id: <87ll7fhnr4.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> <36b15b1135c025234f12d1646a216f6f@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Graham was heard to say: | I'd also like to remove the word "normal" from there, since these | aren't normal for text/plain, which is the obvious analogy. Do I get what I expect if I specify the content with the MIME type "text/plain"? That is, a monospaced font with line breaks and other whitespace preserved? Be seeing you, norm =2D-=20 Norman Walsh | Everything should be made as simple as http://nwalsh.com/ | possible, but no simpler. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCZA5/OyltUcwYWjsRAq3OAJ4qyDKmx+nDAR+4FGtCMABhERbaMACgghi1 5f+m4sYZ5OSWcVce/m5A5H4= =JZ1x -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Mon Apr 18 16:10:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00775 for ; Mon, 18 Apr 2005 16:10:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IJvMwV021306; Mon, 18 Apr 2005 12:57:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IJvM2r021305; Mon, 18 Apr 2005 12:57:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IJvMNK021290 for ; Mon, 18 Apr 2005 12:57:22 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-2 ([129.148.9.73]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3IJvLjQ014340 for ; Mon, 18 Apr 2005 13:57:21 -0600 (MDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IF500J01RBI6T@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Mon, 18 Apr 2005 15:57:21 -0400 (EDT) Received: from localhost (vpn-129-150-32-107.Central.Sun.COM [129.150.32.107]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IF500GUYRFKLS@bur-mail1.east.sun.com>; Mon, 18 Apr 2005 15:57:21 -0400 (EDT) Received: from ndw by localhost with local (Exim 4.50) id 1DNcN9-0002Zy-MI; Mon, 18 Apr 2005 15:57:31 -0400 X-URL: http://nwalsh.com/ Date: Mon, 18 Apr 2005 15:57:25 -0400 From: Norman Walsh Subject: Re: Extensions containing Atom elements In-reply-to: <4263F17A.7040009@franklinmint.fm> To: atom-syntax@imc.org Cc: Robert Sayre Message-id: <87hdi3hn8a.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) References: <425491E7.3020605@dehora.net> <7910428092.20050407231536@djpowell.net> <426127D2.3080002@franklinmint.fm> <87acnwgf9y.fsf@nwalsh.com> <4263F17A.7040009@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Robert Sayre was heard to say: | Norman Walsh wrote: | |> The point is that extensions should allow atom:content inside the |> extension, is that right? | | Yes. Any atom element should be allowed in an extension. Fix appended. And I happened to notice that our example feed in 1.1 is invalid. It does not contain an atom:link element with a relation of "alternat". # -*- rnc -*- # RELAX NG Compact Syntax Grammar for the # Atom Format Specification Version 07+ namespace atom =3D "http://purl.org/atom/ns#draft-ietf-atompub-format-07" namespace xhtml =3D "http://www.w3.org/1999/xhtml" namespace s =3D "http://www.ascc.net/xml/schematron" start =3D atomFeed | atomEntry # Common attributes atomCommonAttributes =3D attribute xml:base { atomUri }?, attribute xml:lang { atomLanguageTag }? # Text Constructs atomPlainTextConstruct =3D atomCommonAttributes, attribute type { "text" | "html" }?, text atomXHTMLTextConstruct =3D atomCommonAttributes, attribute type { "xhtml" }, xhtmlDiv atomTextConstruct =3D atomPlainTextConstruct | atomXHTMLTextConstruct # Person Construct atomPersonConstruct =3D atomCommonAttributes, (element atom:name { text } & element atom:uri { atomUri }? & element atom:email { atomEmailAddress }? & extensionElement*) # Date Construct atomDateConstruct =3D atomCommonAttributes, xsd:dateTime # atom:feed atomFeed =3D [ s:rule [ context =3D "atom:feed" s:assert [ test =3D "atom:link[@rel=3D'alternate']" "An atom:feed must have at least one link element " ~ "with a rel attribute of 'alternate'." ] ] s:rule [ context =3D "atom:feed" s:assert [ test =3D "atom:author or not(atom:entry[not(atom:author)])" "An atom:feed must have an atom:author unless all " ~ "of its atom:entry children have an atom:author." ] ] ] element atom:feed { atomCommonAttributes, (atomAuthor? & atomCategory* & atomContributor* & atomCopyright? & atomGenerator? & atomIcon? & atomId? & atomImage? & atomLink+ & atomSubtitle? & atomTitle & atomUpdated & extensionElement*), atomEntry* } # atom:entry atomEntry =3D [ s:rule [ context =3D "atom:entry" s:assert [ test =3D "atom:link[@rel=3D'alternate'] or atom:content" "An atom:entry must have at least one link element " ~ "with a rel attribute of 'alternate' or content." ] ] s:rule [ context =3D "atom:entry" s:assert [ test =3D "atom:author or " ~ "../atom:author or atom:source/atom:author" "An atom:entry must have an atom:author " ~ "if its feed does not." ] ] # N.B. This rule doesn't test for content with a non-binary type. s:rule [ context =3D "atom:entry" s:assert [ test =3D "atom:summary or atom:content[not(@src)]" "An atom:entry must have an atom:summary " ~ "if the atom:content element is empty." ] ] ] element atom:entry { atomCommonAttributes, (atomAuthor? & atomCategory* & atomContent? & atomContributor* & atomCopyright? & atomId & atomLink* & atomPublished? & atomSource? & atomSummary? & atomTitle & atomUpdated & extensionElement*) } # atom:content atomInlineTextContent =3D element atom:content { atomCommonAttributes, attribute type { "text" | "html" }?, (text)* } atomInlineXHTMLContent =3D element atom:content { atomCommonAttributes, attribute type { "xhtml" }, xhtmlDiv } atomInlineOtherContent =3D element atom:content { atomCommonAttributes, attribute type { atomMediaType }?, (text|anyForeignElement)* } atomOutOfLineContent =3D element atom:content { atomCommonAttributes, attribute type { atomMediaType }?, attribute src { atomUri }, empty } atomContent =3D atomInlineTextContent | atomInlineXHTMLContent | atomInlineOtherContent | atomOutOfLineContent # atom:author atomAuthor =3D element atom:author { atomPersonConstruct } # atom:category atomCategory =3D element atom:category { atomCommonAttributes, attribute term { text }, attribute scheme { atomUri }?, attribute label { text }?, empty } # atom:contributor atomContributor =3D element atom:contributor { atomPersonConstruct } # atom:copyright atomCopyright =3D element atom:copyright { atomTextConstruct } # atom:generator atomGenerator =3D element atom:generator { atomCommonAttributes, attribute url { atomUri }?, attribute version { text }?, text } # atom:icon atomIcon =3D element atom:icon { atomCommonAttributes, (atomUri) } # atom:id atomId =3D element atom:id { atomCommonAttributes, (atomUri) } # atom:image atomImage =3D element atom:image { atomCommonAttributes, (atomUri) } # atom:link atomLink =3D element atom:link { atomCommonAttributes, attribute href { atomUri }, attribute rel { atomNCName | atomUri }?, attribute type { atomMediaType }?, attribute hreflang { atomLanguageTag }?, attribute title { text }?, attribute length { text }?, empty } # atom:published atomPublished =3D element atom:published { atomDateConstruct } # atom:source atomSource =3D element atom:source { atomCommonAttributes, (atomAuthor? & atomCategory* & atomContributor* & atomCopyright? & atomGenerator? & atomIcon? & atomId? & atomImage? & atomLink+ & atomSubtitle? & atomTitle & atomUpdated & extensionElement*) } # atom:subtitle atomSubtitle =3D element atom:subtitle { atomTextConstruct } # atom:summary atomSummary =3D element atom:summary { atomTextConstruct } # atom:title atomTitle =3D element atom:title { atomTextConstruct } # atom:updated atomUpdated =3D element atom:updated { atomDateConstruct } # Low-level simple types atomNCName =3D xsd:string { minLength =3D "1" pattern =3D "[^:]*" } # Whatever a media type is, it contains at least one slash atomMediaType =3D xsd:string { pattern =3D ".+/.+" } # As defined in RFC 3066 atomLanguageTag =3D xsd:string { pattern =3D "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*" } # Unconstrained; it's not entirely clear how IRI fit into # xsd:anyURI so let's not try to constrain it here atomUri =3D text # Whatever an email address is, it contains at least one @ atomEmailAddress =3D xsd:string { pattern =3D ".+@.+" } # Extensibility simpleExtensionElement =3D element * - atom:* { text } structuredExtensionElement =3D element * - atom:* { (attribute * { text }+, (text|anyElement)*) | (attribute * { text }*, (text?, anyElement+, (text|anyElement)*)) } extensionElement =3D simpleExtensionElement | structuredExtensionElement anyElement =3D element * { (attribute * { text } | text | anyElement)* } anyForeignElement =3D element * - atom:* { (attribute * { text } | text | anyElement)* } # XHTML anyXHTML =3D element xhtml:* { (attribute * { text } | text | anyXHTML)* } xhtmlDiv =3D element xhtml:div { (attribute * { text } | text | anyXHTML)* } # EOF Be seeing you, norm =2D-=20 Norman Walsh | Everything should be made as simple as http://nwalsh.com/ | possible, but no simpler. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCZBEmOyltUcwYWjsRAm0uAJsGp8kHqU4KAgn4V8IF2hu2erdHyQCcCltH Hna5W6ysfnPGsTGOe0a71pc= =pMFH -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Mon Apr 18 16:12:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01232 for ; Mon, 18 Apr 2005 16:12:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IK2YVp021988; Mon, 18 Apr 2005 13:02:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IK2Ywm021987; Mon, 18 Apr 2005 13:02:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IK2XI0021978 for ; Mon, 18 Apr 2005 13:02:33 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.3]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DNcRn-00034h-AX; Mon, 18 Apr 2005 20:02:19 +0000 Message-ID: <4264124D.4010902@franklinmint.fm> Date: Mon, 18 Apr 2005 16:02:21 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Walsh CC: atom-syntax@imc.org Subject: Re: Extensions containing Atom elements References: <425491E7.3020605@dehora.net> <7910428092.20050407231536@djpowell.net> <426127D2.3080002@franklinmint.fm> <87acnwgf9y.fsf@nwalsh.com> <4263F17A.7040009@franklinmint.fm> <87hdi3hn8a.fsf@nwalsh.com> In-Reply-To: <87hdi3hn8a.fsf@nwalsh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > / Robert Sayre was heard to say: > | Norman Walsh wrote: > | > |> The point is that extensions should allow atom:content inside the > |> extension, is that right? > | > | Yes. Any atom element should be allowed in an extension. > > Fix appended. Thank you. > And I happened to notice that our example feed in 1.1 is invalid. > It does not contain an atom:link element with a relation of > "alternate". It's valid, because link elements without the rel attribute have a relation of "alternate".[0] Robert Sayre [0] From owner-atom-syntax@mail.imc.org Mon Apr 18 17:02:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11874 for ; Mon, 18 Apr 2005 17:02:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IKrWN3028394; Mon, 18 Apr 2005 13:53:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3IKrWFn028393; Mon, 18 Apr 2005 13:53:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3IKrWOU028377 for ; Mon, 18 Apr 2005 13:53:32 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-2 ([129.148.9.73]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3IKrVjO026435 for ; Mon, 18 Apr 2005 14:53:31 -0600 (MDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IF500L01TYQGK@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Mon, 18 Apr 2005 16:53:31 -0400 (EDT) Received: from localhost (vpn-129-150-32-107.Central.Sun.COM [129.150.32.107]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IF500GE6U16LS@bur-mail1.east.sun.com> for atom-syntax@imc.org; Mon, 18 Apr 2005 16:53:31 -0400 (EDT) Received: from ndw by localhost with local (Exim 4.50) id 1DNdFV-0003Ve-Om for atom-syntax@imc.org; Mon, 18 Apr 2005 16:53:41 -0400 X-URL: http://nwalsh.com/ Date: Mon, 18 Apr 2005 16:53:36 -0400 From: Norman Walsh Subject: Re: Extensions containing Atom elements In-reply-to: <4264124D.4010902@franklinmint.fm> To: atom-syntax@imc.org Message-id: <87k6mzajsf.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="==-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) References: <425491E7.3020605@dehora.net> <7910428092.20050407231536@djpowell.net> <426127D2.3080002@franklinmint.fm> <87acnwgf9y.fsf@nwalsh.com> <4263F17A.7040009@franklinmint.fm> <87hdi3hn8a.fsf@nwalsh.com> <4264124D.4010902@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain / Robert Sayre was heard to say: | It's valid, because link elements without the rel attribute have a | relation of "alternate".[0] Oops. Then my Schematron is wrong. Fixed and formatted for 72 cols. --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=atom.rnc # -*- rnc -*- # RELAX NG Compact Syntax Grammar for the # Atom Format Specification Version 07 namespace atom = "http://purl.org/atom/ns#draft-ietf-atompub-format-07" namespace xhtml = "http://www.w3.org/1999/xhtml" namespace s = "http://www.ascc.net/xml/schematron" start = atomFeed | atomEntry # Common attributes atomCommonAttributes = attribute xml:base { atomUri }?, attribute xml:lang { atomLanguageTag }? # Text Constructs atomPlainTextConstruct = atomCommonAttributes, attribute type { "text" | "html" }?, text atomXHTMLTextConstruct = atomCommonAttributes, attribute type { "xhtml" }, xhtmlDiv atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct # Person Construct atomPersonConstruct = atomCommonAttributes, (element atom:name { text } & element atom:uri { atomUri }? & element atom:email { atomEmailAddress }? & extensionElement*) # Date Construct atomDateConstruct = atomCommonAttributes, xsd:dateTime # atom:feed atomFeed = [ s:rule [ context = "atom:feed" s:assert [ test = "atom:link[@rel='alternate'] " ~ "or atom:link[not(@rel)]" "An atom:feed must have at least one link element " ~ "with a rel attribute of 'alternate'." ] ] s:rule [ context = "atom:feed" s:assert [ test = "atom:author or not(atom:entry[not(atom:author)])" "An atom:feed must have an atom:author unless all " ~ "of its atom:entry children have an atom:author." ] ] ] element atom:feed { atomCommonAttributes, (atomAuthor? & atomCategory* & atomContributor* & atomCopyright? & atomGenerator? & atomIcon? & atomId? & atomImage? & atomLink+ & atomSubtitle? & atomTitle & atomUpdated & extensionElement*), atomEntry* } # atom:entry atomEntry = [ s:rule [ context = "atom:entry" s:assert [ test = "atom:link[@rel='alternate'] " ~ "or atom:link[not(@rel)] " ~ "or atom:content" "An atom:entry must have at least one link element " ~ "with a rel attribute of 'alternate' or content." ] ] s:rule [ context = "atom:entry" s:assert [ test = "atom:author or " ~ "../atom:author or atom:source/atom:author" "An atom:entry must have an atom:author " ~ "if its feed does not." ] ] # N.B. This rule doesn't test for content with a non-binary type. s:rule [ context = "atom:entry" s:assert [ test = "atom:summary or atom:content[not(@src)]" "An atom:entry must have an atom:summary " ~ "if the atom:content element is empty." ] ] ] element atom:entry { atomCommonAttributes, (atomAuthor? & atomCategory* & atomContent? & atomContributor* & atomCopyright? & atomId & atomLink* & atomPublished? & atomSource? & atomSummary? & atomTitle & atomUpdated & extensionElement*) } # atom:content atomInlineTextContent = element atom:content { atomCommonAttributes, attribute type { "text" | "html" }?, (text)* } atomInlineXHTMLContent = element atom:content { atomCommonAttributes, attribute type { "xhtml" }, xhtmlDiv } atomInlineOtherContent = element atom:content { atomCommonAttributes, attribute type { atomMediaType }?, (text|anyForeignElement)* } atomOutOfLineContent = element atom:content { atomCommonAttributes, attribute type { atomMediaType }?, attribute src { atomUri }, empty } atomContent = atomInlineTextContent | atomInlineXHTMLContent | atomInlineOtherContent | atomOutOfLineContent # atom:author atomAuthor = element atom:author { atomPersonConstruct } # atom:category atomCategory = element atom:category { atomCommonAttributes, attribute term { text }, attribute scheme { atomUri }?, attribute label { text }?, empty } # atom:contributor atomContributor = element atom:contributor { atomPersonConstruct } # atom:copyright atomCopyright = element atom:copyright { atomTextConstruct } # atom:generator atomGenerator = element atom:generator { atomCommonAttributes, attribute url { atomUri }?, attribute version { text }?, text } # atom:icon atomIcon = element atom:icon { atomCommonAttributes, (atomUri) } # atom:id atomId = element atom:id { atomCommonAttributes, (atomUri) } # atom:image atomImage = element atom:image { atomCommonAttributes, (atomUri) } # atom:link atomLink = element atom:link { atomCommonAttributes, attribute href { atomUri }, attribute rel { atomNCName | atomUri }?, attribute type { atomMediaType }?, attribute hreflang { atomLanguageTag }?, attribute title { text }?, attribute length { text }?, empty } # atom:published atomPublished = element atom:published { atomDateConstruct } # atom:source atomSource = element atom:source { atomCommonAttributes, (atomAuthor? & atomCategory* & atomContributor* & atomCopyright? & atomGenerator? & atomIcon? & atomId? & atomImage? & atomLink+ & atomSubtitle? & atomTitle & atomUpdated & extensionElement*) } # atom:subtitle atomSubtitle = element atom:subtitle { atomTextConstruct } # atom:summary atomSummary = element atom:summary { atomTextConstruct } # atom:title atomTitle = element atom:title { atomTextConstruct } # atom:updated atomUpdated = element atom:updated { atomDateConstruct } # Low-level simple types atomNCName = xsd:string { minLength = "1" pattern = "[^:]*" } # Whatever a media type is, it contains at least one slash atomMediaType = xsd:string { pattern = ".+/.+" } # As defined in RFC 3066 atomLanguageTag = xsd:string { pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*" } # Unconstrained; it's not entirely clear how IRI fit into # xsd:anyURI so let's not try to constrain it here atomUri = text # Whatever an email address is, it contains at least one @ atomEmailAddress = xsd:string { pattern = ".+@.+" } # Extensibility simpleExtensionElement = element * - atom:* { text } structuredExtensionElement = element * - atom:* { (attribute * { text }+, (text|anyElement)*) | (attribute * { text }*, (text?, anyElement+, (text|anyElement)*)) } extensionElement = simpleExtensionElement | structuredExtensionElement anyElement = element * { (attribute * { text } | text | anyElement)* } anyForeignElement = element * - atom:* { (attribute * { text } | text | anyElement)* } # XHTML anyXHTML = element xhtml:* { (attribute * { text } | text | anyXHTML)* } xhtmlDiv = element xhtml:div { (attribute * { text } | text | anyXHTML)* } # EOF --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Be seeing you, norm =2D-=20 Norman Walsh | Thanks to words, we have been able to http://nwalsh.com/ | rise above the brutes; and thanks to | words, we have often sunk to the level | of the demons.--Aldous Huxley --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCZB5QOyltUcwYWjsRAmHJAJ47x1M3pU1cWPolMAEy8NqOt+PoJQCffe1C ZyfpL8tNKvMSBlyqkTGuNTg= =YQXm -----END PGP SIGNATURE----- --==-=-=-- From owner-atom-syntax@mail.imc.org Mon Apr 18 20:20:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26713 for ; Mon, 18 Apr 2005 20:20:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J08vXY055187; Mon, 18 Apr 2005 17:08:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3J08vBG055186; Mon, 18 Apr 2005 17:08:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from server0.24hostingnow.com (server0.24hostingnow.com [69.72.226.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J08u26055180 for ; Mon, 18 Apr 2005 17:08:56 -0700 (PDT) (envelope-from fantasai.lists@inkedblade.net) Received: from eetemad.student.princeton.edu ([140.180.146.72]) by server0.24hostingnow.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DNgIO-0007sB-2e for atom-syntax@imc.org; Mon, 18 Apr 2005 20:08:52 -0400 Message-ID: <42644BF8.3010906@inkedblade.net> Date: Mon, 18 Apr 2005 20:08:24 -0400 From: fantasai User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: How should this be rendered? References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> <20050416230226.GA1894@klangraum> <4263F79E.9050203@cegetel.net> <4263F8BA.5010500@annevankesteren.nl> In-Reply-To: <4263F8BA.5010500@annevankesteren.nl> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PopBeforeSMTPSenders: fantasai.lists@inkedblade.net,fantasai@inkedblade.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server0.24hostingnow.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - inkedblade.net Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > > Thomas Broyer wrote: > >> (or any element using the CSS "white-space" property) > > That is purely for presentation. You should not use it if you need > whitespace to be preserverd for semantics. (In such cases xml:space > would probably be more appropriate...) Even if you use xml:space to make the parser preserve white space, unless the computed value of CSS 'white-space' is 'pre', a CSS renderer must collapse the white space. xml:space controls whether the parser collapses white space or not. CSS 'white-space' controls whether the white space passed from the parser to the renderer is collapsed or not. If the parser collapses whitespace, CSS will never see it. ~fantasai From owner-atom-syntax@mail.imc.org Mon Apr 18 21:25:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00872 for ; Mon, 18 Apr 2005 21:25:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J1HRGM068721; Mon, 18 Apr 2005 18:17:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3J1HR2E068719; Mon, 18 Apr 2005 18:17:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J1HQat068686 for ; Mon, 18 Apr 2005 18:17:26 -0700 (PDT) (envelope-from ldrhcp@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2699518wra for ; Mon, 18 Apr 2005 18:17:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=san9LqgnLJZSKmrsU+xUhcpY/rWo3hiHIfh4wdoZfuLRTmb9bgAbOA2jCKnaJ0u3M6dF/0v/EZle3inRk2ABs3eDtRWk7XqRmkfUsWepqzk+4Elu+9jlwvep2twn+3ribTRC3pLHgfNYIdXzdxVYRMEZ1WqWAK0Vy8PPwvmNv4w= Received: by 10.54.40.34 with SMTP id n34mr4971857wrn; Mon, 18 Apr 2005 18:17:21 -0700 (PDT) Received: by 10.54.41.46 with HTTP; Mon, 18 Apr 2005 18:17:21 -0700 (PDT) Message-ID: <94355ecc05041818174b1be18@mail.gmail.com> Date: Mon, 18 Apr 2005 21:17:21 -0400 From: Lenny Domnitser Reply-To: Lenny Domnitser To: atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... In-Reply-To: <94355ecc0504111530635abb64@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <94355ecc0504111530635abb64@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3J1HRat068709 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Regarding the potential for a DoS attack with stealing somebody else's GUIDs, no special hacks [1] are needed. Any decent aggregator would trust IDs with a grain of salt. * If the IDs of two entries from different feeds are the same **and the data is the same** show it in only one feed. * If the IDs of two entries from different feeds are the same and the data is different, this can be one of two things: a DoS attack or an update to the entry. In either case, show the updated version without wiping out the old one. * If two entries with the same ID are from the same feed, this can't be a DoS, so only show the new one, unless the user wants it otherwise. [1]: http://www.imc.org/atom-syntax/mail-archive/msg14094.html From owner-atom-syntax@mail.imc.org Mon Apr 18 22:57:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06924 for ; Mon, 18 Apr 2005 22:57:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J2eZIv087140; Mon, 18 Apr 2005 19:40:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3J2eZEJ087138; Mon, 18 Apr 2005 19:40:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J2eTcT087104 for ; Mon, 18 Apr 2005 19:40:29 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3J2eTi7001528 for ; Mon, 18 Apr 2005 20:40:29 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IF6001FCA3GQL@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 18 Apr 2005 20:40:29 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IF600HB7A3GJS@mail.sun.net> for atom-syntax@imc.org; Mon, 18 Apr 2005 20:40:28 -0600 (MDT) Date: Mon, 18 Apr 2005 19:41:12 -0700 From: Tim Bray Subject: Re: How should this be rendered? In-reply-to: <42644BF8.3010906@inkedblade.net> To: fantasai Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> <20050416230226.GA1894@klangraum> <4263F79E.9050203@cegetel.net> <4263F8BA.5010500@annevankesteren.nl> <42644BF8.3010906@inkedblade.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 18, 2005, at 5:08 PM, fantasai wrote: > xml:space controls whether the parser collapses white space or > not. False. Parsers are not under any obligation to respect xml:space, unless they are governed by some other specification that says they are. -Tim > If the > parser collapses whitespace, CSS will never see it. True. -Tim From owner-atom-syntax@mail.imc.org Mon Apr 18 23:07:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07619 for ; Mon, 18 Apr 2005 23:07:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J2pffE089105; Mon, 18 Apr 2005 19:51:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3J2pfkc089104; Mon, 18 Apr 2005 19:51:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J2pRw1089061 for ; Mon, 18 Apr 2005 19:51:35 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 19 Apr 2005 12:51:01 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 19 Apr 2005 12:51:04 +1000 Subject: Re: How should this be rendered? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 19/4/05 12:41 PM, "Tim Bray" wrote: >> xml:space controls whether the parser collapses white space or >> not. > > False. Parsers are not under any obligation to respect xml:space, > unless they are governed by some other specification that says they > are. -Tim some other specification = Atom Pub spec? e. From owner-atom-syntax@mail.imc.org Tue Apr 19 00:09:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10526 for ; Tue, 19 Apr 2005 00:09:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J3r4No000518; Mon, 18 Apr 2005 20:53:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3J3r4CV000517; Mon, 18 Apr 2005 20:53:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J3r4Ee000511 for ; Mon, 18 Apr 2005 20:53:04 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j3J3r2Wl005574; Mon, 18 Apr 2005 23:53:02 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CZF80272; Mon, 18 Apr 2005 23:53:01 -0400 (EDT) Message-Id: <200504190353.CZF80272@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Lenny Domnitser'" , Subject: RE: One reason we have duplicates entries is that we have duplicate feeds... Date: Mon, 18 Apr 2005 23:52:59 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVEgM3ZDNj5G844S4OnkidqbbKzOgAEmeOg In-Reply-To: <94355ecc05041818174b1be18@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Lenny Domnitser wrote: > * If the IDs of two entries from different feeds are the same and the > data is different, this can be one of two things: a DoS attack or an > update to the entry. In either case, show the updated version without > wiping out the old one. What if the two entries are both found in the same feed but have different source feeds identified in their atom:source elements? These two entries are clearly *from* different feeds, yet they might be found in a single feed. The problem here is, of course, that 4.1.1 of the specification says: "atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values." Thus, one of the two entries should not have been written to the feed. Which of the two entries should NOT have been written? Note: There is no good answer here. You might have an attack or you might just have a "secondary" copied entry that is being inserted. In any case, there isn't enough info to know which to accept and which to reject. So... I believe that the prohibition against multiple entries with identical IDs should be relaxed to say: "atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values unless each such entry contains an atom:source element which is different from that of any of the other entries with which the entry shares identical atom:id values. Two or more atom:source elements MUST only be considered different if they each contain an atom:link element with a rel value of "self" which identifies different feed URIs." Yes, I know that language is very tortured... In any case, you can't build a synthetic feed generator which is robust against attack unless the proposed relaxation is supported. ID's must be feed specific where feed is defined as the source feed -- not the feed in which the entry is found. bob wyman From owner-atom-syntax@mail.imc.org Tue Apr 19 00:48:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12808 for ; Tue, 19 Apr 2005 00:48:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J4VZqI006419; Mon, 18 Apr 2005 21:31:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3J4VZNp006418; Mon, 18 Apr 2005 21:31:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J4VXOs006401 for ; Mon, 18 Apr 2005 21:31:34 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:50271 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228698AbVDSEbc (ORCPT ); Tue, 19 Apr 2005 07:31:32 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> <20050416230226.GA1894@klangraum> <4263F79E.9050203@cegetel.net> <4263F8BA.5010500@annevankesteren.nl> <42644BF8.3010906@inkedblade.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: How should this be rendered? Date: Tue, 19 Apr 2005 07:31:16 +0300 To: Atom Syntax X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 19, 2005, at 05:41, Tim Bray wrote: > On Apr 18, 2005, at 5:08 PM, fantasai wrote: > >> xml:space controls whether the parser collapses white space or >> not. > > False. Parsers are not under any obligation to respect xml:space, > unless they are governed by some other specification that says they > are. -Tim How can a spec other than the XML spec govern what XML processors do? Or is xml:space supposed to be handled somewhere between the XML processor and the app? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Tue Apr 19 00:55:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10543 for ; Tue, 19 Apr 2005 00:09:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J3pnQq000377; Mon, 18 Apr 2005 20:51:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3J3pn0s000376; Mon, 18 Apr 2005 20:51:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J3pnsN000366 for ; Mon, 18 Apr 2005 20:51:49 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by mail.pubsub.com (Postfix) with ESMTP id EADA472402A; Mon, 18 Apr 2005 23:51:43 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Lenny Domnitser'" , Subject: RE: One reason we have duplicates entries is that we have duplicate feeds... Date: Mon, 18 Apr 2005 23:51:42 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVEgM3ZDNj5G844S4OnkidqbbKzOgADm4ag In-Reply-To: <94355ecc05041818174b1be18@mail.gmail.com> Message-Id: <20050419035143.EADA472402A@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Lenny Domnitser wrote: > * If the IDs of two entries from different feeds are the same and the > data is different, this can be one of two things: a DoS attack or an > update to the entry. In either case, show the updated version without > wiping out the old one. What if the two entries are both found in the same feed but have different source feeds identified in their atom:source elements? These two entries are clearly *from* different feeds, yet they might be found in a single feed. The problem here is, of course, that 4.1.1 of the specification says: "atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values." Thus, one of the two entries should not have been written to the feed. Which of the two entries should NOT have been written? Note: There is no good answer here. You might have an attack or you might just have a "secondary" copied entry that is being inserted. In any case, there isn't enough info to know which to accept and which to reject. So... I believe that the prohibition against multiple entries with identical IDs should be relaxed to say: "atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values unless each such entry contains an atom:source element which is different from that of any of the other entries with which the entry shares identical atom:id values. Two or more atom:source elements MUST only be considered different if they each contain an atom:link element with a rel value of "self" which identifies different feed URIs." Yes, I know that language is very tortured... In any case, you can't build a synthetic feed generator which is robust against attack unless the proposed relaxation is supported. ID's must be feed specific where feed is defined as the source feed -- not the feed in which the entry is found. bob wyman From owner-atom-syntax@mail.imc.org Tue Apr 19 01:26:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15615 for ; Tue, 19 Apr 2005 01:26:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J5HrpG018503; Mon, 18 Apr 2005 22:17:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3J5Hrsi018502; Mon, 18 Apr 2005 22:17:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J5HpBP018487 for ; Mon, 18 Apr 2005 22:17:51 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3J5HpjO001352 for ; Mon, 18 Apr 2005 23:17:51 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IF600CIJHDQ46@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 18 Apr 2005 23:17:50 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IF6002U1HDPUG@mail.sun.net> for atom-syntax@imc.org; Mon, 18 Apr 2005 23:17:50 -0600 (MDT) Date: Mon, 18 Apr 2005 22:18:34 -0700 From: Tim Bray Subject: Re: How should this be rendered? In-reply-to: To: Henri Sivonen Cc: Atom Syntax Message-id: <89c2c6cd98579e7de029ff269b160e0c@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <6329ffdcfe698abbc9922176d0ff3458@mac.com> <42616899.8080709@franklinmint.fm> <20050416230226.GA1894@klangraum> <4263F79E.9050203@cegetel.net> <4263F8BA.5010500@annevankesteren.nl> <42644BF8.3010906@inkedblade.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 18, 2005, at 9:31 PM, Henri Sivonen wrote: >> False. Parsers are not under any obligation to respect xml:space, >> unless they are governed by some other specification that says they >> are. -Tim > > How can a spec other than the XML spec govern what XML processors do? > Or is xml:space supposed to be handled somewhere between the XML > processor and the app? An Atom processor, for example, is larger than the XML processor, which is a glorified input buffer and is anyhow forbidden from removing white space in element content. xml:space is a value which may be used upstream in an XML transmission chain to express an intent about white-space handling to those further downstream in the chain. It wouldn't break any rules for Atom to impose requirements on Atom-processing software as regards the handling of xml:space. However, I don't think we should. The semantics are clear: someone upstream thinks this white-space is specific. Whoever reads the Atom feed is at liberty to respect or to ignore xml:space. Whatever we say, full-text indexers, for example, are guaranteed to ignore it. I don't see where we can add any value. -Tim From owner-atom-syntax@mail.imc.org Tue Apr 19 04:21:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16894 for ; Tue, 19 Apr 2005 04:21:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3J8DR1i086873; Tue, 19 Apr 2005 01:13:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3J8DRCC086870; Tue, 19 Apr 2005 01:13:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3J8DQOD086739 for ; Tue, 19 Apr 2005 01:13:27 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 19706 messnum 2891614 invoked from network[83.70.217.193/unknown]); 19 Apr 2005 08:13:20 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail07.svc.cra.dublin.eircom.net (qp 19706) with SMTP; 19 Apr 2005 08:13:20 -0000 Message-ID: <4264BD9D.4050204@dehora.net> Date: Tue, 19 Apr 2005 09:13:17 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... References: <200504190353.CZF80272@ms8.netsolmail.com> In-Reply-To: <200504190353.CZF80272@ms8.netsolmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > What if the two entries are both found in the same feed but have > different source feeds identified in their atom:source elements? These two > entries are clearly *from* different feeds, yet they might be found in a > single feed. Not clearly; one or more of them might be misattributed. > The problem here is, of course, that 4.1.1 of the specification > says: "atom:feed elements MUST NOT contain atom:entry elements with > identical atom:id values." Thus, one of the two entries should not have been > written to the feed. Which of the two entries should NOT have been written? > Note: There is no good answer here. You might have an attack or you might > just have a "secondary" copied entry that is being inserted. In any case, > there isn't enough info to know which to accept and which to reject. So... > I believe that the prohibition against multiple entries with > identical IDs should be relaxed to say: [...] We discussed this and the consensus said that the prohibition should stand (iirc I was pro multiple IDs in a feed). As it happens I think error handling will be contextual in reality - I really doubt client aggregators will drop an entire planet* Atom feed because two entries have the same ID. > "atom:feed elements MUST NOT contain atom:entry elements with > identical atom:id values unless each such entry contains an atom:source > element which is different from that of any of the other entries with which > the entry shares identical atom:id values. Two or more atom:source elements > MUST only be considered different if they each contain an atom:link element > with a rel value of "self" which identifies different feed URIs." > Yes, I know that language is very tortured... In any case, you can't > build a synthetic feed generator which is robust against attack unless the > proposed relaxation is supported. ID's must be feed specific where feed is > defined as the source feed -- not the feed in which the entry is found. I'm going to think about it some more but atm I'm not sure what you're proposing helps against DOS. cheers Bill From owner-atom-syntax@mail.imc.org Tue Apr 19 12:23:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24166 for ; Tue, 19 Apr 2005 12:23:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JGCoeO004380; Tue, 19 Apr 2005 09:12:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JGCo3v004379; Tue, 19 Apr 2005 09:12:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JGCndE004372 for ; Tue, 19 Apr 2005 09:12:49 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 49167 invoked by uid 17064); 19 Apr 2005 16:12:49 -0000 Received: from unknown (HELO [192.168.1.40]) ([81.62.41.121]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 19 Apr 2005 16:12:49 -0000 In-Reply-To: <4264BD9D.4050204@dehora.net> References: <200504190353.CZF80272@ms8.netsolmail.com> <4264BD9D.4050204@dehora.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <87c8fc7ef2bc3b15fad5ad3eeb5b510b@bblfish.net> Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= From: Henry Story Subject: call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds... Date: Tue, 19 Apr 2005 18:12:46 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3JGCodE004374 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I don't see where the consensus was by the way. And I never saw any vote on the issue. Like most issues one gets the impression that Atom is run on some pretense democracy. Some people have made up their minds for god knows what reason, and others are just here to follow. The more we chatter on this group the more we lend credence to the notion that there was some consulting done on the issues. But any carefully crafted arguments put in favor of any issue are ignored. No wonder any attempt to be precise about issues gets ignored here, as that may just reveal the corruption behind the scenes. As far as I can remember not one good reason was put forward as to why there should be a restriction of one entry with the same id per feed. In fact I was nearly convinced that the consensus was to drop the restriction. So I call for a real open vote on the issue. Henry Story On 19 Apr 2005, at 10:13, Bill de hÓra wrote: > >> The problem here is, of course, that 4.1.1 of the specification >> says: "atom:feed elements MUST NOT contain atom:entry elements with >> identical atom:id values." Thus, one of the two entries should not >> have been >> written to the feed. Which of the two entries should NOT have been >> written? >> Note: There is no good answer here. You might have an attack or you >> might >> just have a "secondary" copied entry that is being inserted. In any >> case, >> there isn't enough info to know which to accept and which to reject. >> So... >> I believe that the prohibition against multiple entries with >> identical IDs should be relaxed to say: [...] > > We discussed this and the consensus said that the prohibition should > stand (iirc I was pro multiple IDs in a feed). As it happens I think > error handling will be contextual in reality - I really doubt client > aggregators will drop an entire planet* Atom feed because two entries > have the same ID. From owner-atom-syntax@mail.imc.org Tue Apr 19 12:36:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25060 for ; Tue, 19 Apr 2005 12:36:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JGRnKR007929; Tue, 19 Apr 2005 09:27:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JGRn8M007928; Tue, 19 Apr 2005 09:27:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3JGRm4c007902 for ; Tue, 19 Apr 2005 09:27:49 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 76278 messnum 4219344 invoked from network[213.94.211.166/dev2.mcpps.com]); 19 Apr 2005 16:27:39 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail13.svc.cra.dublin.eircom.net (qp 76278) with SMTP; 19 Apr 2005 16:27:39 -0000 Message-ID: <42653178.5080508@dehora.net> Date: Tue, 19 Apr 2005 17:27:36 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds... References: <200504190353.CZF80272@ms8.netsolmail.com> <4264BD9D.4050204@dehora.net> <87c8fc7ef2bc3b15fad5ad3eeb5b510b@bblfish.net> In-Reply-To: <87c8fc7ef2bc3b15fad5ad3eeb5b510b@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: > So I call for a real open vote on the issue. You don't need to call for a vote, just ask the chairs/editors who keep track of such matters, about the particular specification. If you can point out to me my recollection of the consensus on that issue is incorrect, then do so. Beyond that, dark mutterings about corruption carry little weight with me. cheers Bill From owner-atom-syntax@mail.imc.org Tue Apr 19 13:00:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27145 for ; Tue, 19 Apr 2005 13:00:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JGrjSp013297; Tue, 19 Apr 2005 09:53:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JGrjbW013296; Tue, 19 Apr 2005 09:53:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JGrjVV013290 for ; Tue, 19 Apr 2005 09:53:45 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 67088 invoked by uid 17064); 19 Apr 2005 16:53:44 -0000 Received: from unknown (HELO [192.168.1.41]) ([81.62.41.121]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 19 Apr 2005 16:53:44 -0000 In-Reply-To: <42653178.5080508@dehora.net> References: <200504190353.CZF80272@ms8.netsolmail.com> <4264BD9D.4050204@dehora.net> <87c8fc7ef2bc3b15fad5ad3eeb5b510b@bblfish.net> <42653178.5080508@dehora.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <7298c399d88f7a5d66131557f670cef1@bblfish.net> Cc: Atom Syntax From: Henry Story Subject: Re: call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds... Date: Tue, 19 Apr 2005 18:53:41 +0200 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3JGrjVV013291 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 19 Apr 2005, at 18:27, Bill de hÓra wrote: > Henry Story wrote: > >> So I call for a real open vote on the issue. > > You don't need to call for a vote, just ask the chairs/editors who > keep track of such matters, about the particular specification. Well we need some objective way to tell what the consensus is. Going from your or my recollection does not seem to help, since by reading this list we end up with completely different points of view on where the consensus is. > If you can point out to me my recollection of the consensus on that > issue is incorrect, then do so. Beyond that, dark mutterings about > corruption carry little weight with me. We never had a vote so what can I point to? I could point to some people putting forward some arguments and then others putting others forward. The reason we have arguments is in order to convince someone, so how do I know what the consensus is at the end of the argument? People may have changed their position throughout the argument, especially if there are highly intelligent people putting very good reasons forward. On the issue of not allowing more than one entry per feed with the same id, I heard some very bizaare reasons, such as there being a major problem with web architecture that nobody has heard of. But is this a reason that has convinced anyone? > cheers > Bill > From owner-atom-syntax@mail.imc.org Tue Apr 19 13:09:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27816 for ; Tue, 19 Apr 2005 13:09:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JGwmWQ014932; Tue, 19 Apr 2005 09:58:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JGwmCX014931; Tue, 19 Apr 2005 09:58:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JGwknP014914 for ; Tue, 19 Apr 2005 09:58:47 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.3]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DNw3c-0004mC-WF; Tue, 19 Apr 2005 16:58:41 +0000 Message-ID: <426538C1.1070708@franklinmint.fm> Date: Tue, 19 Apr 2005 12:58:41 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story CC: Atom Syntax , =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds... References: <200504190353.CZF80272@ms8.netsolmail.com> <4264BD9D.4050204@dehora.net> <87c8fc7ef2bc3b15fad5ad3eeb5b510b@bblfish.net> In-Reply-To: <87c8fc7ef2bc3b15fad5ad3eeb5b510b@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: > > I don't see where the consensus was by the way. And I never saw any > vote on the issue. Like most issues one gets the impression that Atom > is run on some pretense democracy. There is no voting in the IETF. Please read the beginners' documentation found on ietf.org. Here's a good one: http://www.ietf.org/tao.html > Some people have made up their minds for god knows what reason, and > others are just here to follow. The more we chatter on this group the > more we lend credence to the notion that there was some consulting > done on the issues. But any carefully crafted arguments put in favor > of any issue are ignored. No wonder any attempt to be precise about > issues gets ignored here, as that may just reveal the corruption > behind the scenes. This statement is incredibly inappropriate and offensive. You may have a valid technical point somewhere, but mudslinging is not going to help your case. BTW, Graham's suggestion sounds reasonable. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 19 13:30:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29934 for ; Tue, 19 Apr 2005 13:30:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JHKpfc019130; Tue, 19 Apr 2005 10:20:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JHKpJr019129; Tue, 19 Apr 2005 10:20:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JHKnRM019120 for ; Tue, 19 Apr 2005 10:20:50 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <87c8fc7ef2bc3b15fad5ad3eeb5b510b@bblfish.net> References: <200504190353.CZF80272@ms8.netsolmail.com> <4264BD9D.4050204@dehora.net> <87c8fc7ef2bc3b15fad5ad3eeb5b510b@bblfish.net> Date: Tue, 19 Apr 2005 10:20:46 -0700 To: Atom Syntax From: Paul Hoffman Subject: Re: call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds... Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 6:12 PM +0200 4/19/05, Henry Story wrote: >I don't see where the consensus was by the way. Correct. There was no consensus to remove the current wording. > And I never saw any vote on the >issue. Correct: there was no voting, there was a consensus call. I'm not sure how you could have missed it: PaceRepeatIdInDocument was discussed *heavily* in the past few months. The conclusion was: PaceRepeatIdInDocument Lots of discussion, more -1's than +1's. DISPOSITION: No consensus, close it. But now we have a problem, in that this removed ambiguity in one direction, just closing it leaves the ambiguity. So the only logical conclusion is that the WG is directing the editors to put language in that explicitly forbids entries with duplicate in an . Earlier, PaceMinimalEntryVersioning was dropped because of an even split of views. > Like most issues one gets the impression that Atom is run on some pretense >democracy. Democracy != consensus. (I don't know if there is a math symbol for "emphatically does not equal".) > Some people have made up their minds for god knows what reason, and others >are just here to follow. ...and others have open minds and try to follow debates. > The more we chatter on this group the more we lend credence >to the notion that there was some consulting done on the issues. But >any carefully >crafted arguments put in favor of any issue are ignored. -1. Disagreeing != ignoring. >As far as I can remember not one good reason was put forward as to >why there should >be a restriction of one entry with the same id per feed. In fact I >was nearly convinced >that the consensus was to drop the restriction. See the discussion summary above and see the archives. >So I call for a real open vote on the issue. If you are unhappy with the consensus process and want to move to a voting process, you need to take the Atom work to a venue other than the IETF. The same is true if you want WG participants to be the ones calling for consensus instead of the WG chairs. If what you meant was "I want to move Atom out of the IETF so I can call a vote", please change the subject line of the thread. If what you wanted was for the chairs to again call for consensus on the already-closed Pace, please say so explicitly, possibly without using the phrase "corruption behind the scenes" in your request. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Apr 19 13:57:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02106 for ; Tue, 19 Apr 2005 13:57:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JGUwtF008524; Tue, 19 Apr 2005 09:30:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JGUw6l008523; Tue, 19 Apr 2005 09:30:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JGUvbJ008475 for ; Tue, 19 Apr 2005 09:30:58 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3JGUABb014975; Tue, 19 Apr 2005 17:30:15 +0100 (BST) In-Reply-To: <87c8fc7ef2bc3b15fad5ad3eeb5b510b@bblfish.net> References: <200504190353.CZF80272@ms8.netsolmail.com> <4264BD9D.4050204@dehora.net> <87c8fc7ef2bc3b15fad5ad3eeb5b510b@bblfish.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <11207e72be5ebaf83b63e4661e5fec30@mac.com> Content-Transfer-Encoding: 7bit Cc: "atom-syntax Syntax'" From: Graham Subject: Re: call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds... Date: Tue, 19 Apr 2005 17:30:12 +0100 To: Henry Story X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm in favour of allowing duplicate ids when the source-id is different to simplify creating merged feeds, which would allow the client to figure out what to do. Under any other circumstance, definitely not. Graham From owner-atom-syntax@mail.imc.org Tue Apr 19 14:10:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03394 for ; Tue, 19 Apr 2005 14:10:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JHxKKL026322; Tue, 19 Apr 2005 10:59:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JHxKXo026321; Tue, 19 Apr 2005 10:59:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JHxK56026306 for ; Tue, 19 Apr 2005 10:59:20 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 88345 invoked by uid 17064); 19 Apr 2005 17:59:19 -0000 Received: from unknown (HELO [192.168.1.41]) ([81.62.41.121]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 19 Apr 2005 17:59:19 -0000 In-Reply-To: References: <200504190353.CZF80272@ms8.netsolmail.com> <4264BD9D.4050204@dehora.net> <87c8fc7ef2bc3b15fad5ad3eeb5b510b@bblfish.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23fc4f9d248216b1a08ad28adbc98be6@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds... Date: Tue, 19 Apr 2005 19:59:16 +0200 To: Paul Hoffman X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ok. I am sorry. I thought I had made a really good case for a simple argument to allow multiple entries with the same id in a feed, and thought it had in fact made it into the spec. I then discovered that it still had not. I cleazrly just have no idea how one goes around convincing this group of anything, so I'd better not participate anymore. On 19 Apr 2005, at 19:20, Paul Hoffman wrote: > At 6:12 PM +0200 4/19/05, Henry Story wrote: >> I don't see where the consensus was by the way. > > Correct. There was no consensus to remove the current wording. > >> And I never saw any vote on the >> issue. > > Correct: there was no voting, there was a consensus call. I'm not sure > how you could have missed it: PaceRepeatIdInDocument was discussed > *heavily* in the past few months. The conclusion was: > > PaceRepeatIdInDocument > Lots of discussion, more -1's than +1's. > DISPOSITION: No consensus, close it. But now we have a problem, in > that this removed ambiguity in one direction, just closing it leaves > the ambiguity. So the only logical conclusion is that the WG is > directing the editors to put language in that explicitly forbids > entries with duplicate in an . Yes. I remember the above point very well. And I was very surprised by it. After all here is a decision being made to close a pace and take a decision with regard to it that is not explicitly stated in that Pace without then putting it back forward to the group. I in fact did question that decision and this went on in a long thread PaceRepeatIdInDocumentSolution and so on. I suppose the result of that argument was not clear either. Again I suppose I just don't understand how to make an argument that can convince the group. Henry Story From owner-atom-syntax@mail.imc.org Tue Apr 19 15:04:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08979 for ; Tue, 19 Apr 2005 15:04:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JIuIbR038939; Tue, 19 Apr 2005 11:56:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JIuIRX038938; Tue, 19 Apr 2005 11:56:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JIuIJV038931 for ; Tue, 19 Apr 2005 11:56:18 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 14718 invoked by uid 17064); 19 Apr 2005 18:56:18 -0000 Received: from unknown (HELO [192.168.1.41]) ([81.62.41.121]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 19 Apr 2005 18:56:18 -0000 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <11207e72be5ebaf83b63e4661e5fec30@mac.com> References: <200504190353.CZF80272@ms8.netsolmail.com> <4264BD9D.4050204@dehora.net> <87c8fc7ef2bc3b15fad5ad3eeb5b510b@bblfish.net> <11207e72be5ebaf83b63e4661e5fec30@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1f82362965b9236da2429f299a3a91bc@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds... Date: Tue, 19 Apr 2005 20:56:15 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just to end on a positive note, I'll +1 this suggestion by Graham. Henry On 19 Apr 2005, at 18:30, Graham wrote: > I'm in favour of allowing duplicate ids when the source-id is > different to simplify creating merged feeds, which would allow the > client to figure out what to do. Under any other circumstance, > definitely not. > > Graham > From owner-atom-syntax@mail.imc.org Tue Apr 19 15:08:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09758 for ; Tue, 19 Apr 2005 15:08:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JIxU0Z039342; Tue, 19 Apr 2005 11:59:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JIxUDr039341; Tue, 19 Apr 2005 11:59:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JIxSjT039331 for ; Tue, 19 Apr 2005 11:59:29 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j3JIxPqp019803; Tue, 19 Apr 2005 14:59:26 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CZI81194 (AUTH bob@wyman.us); Tue, 19 Apr 2005 14:59:23 -0400 (EDT) Message-Id: <200504191859.CZI81194@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "=?iso-8859-1?Q?'Bill_de_h=D3ra'?=" , Subject: RE: One reason we have duplicates entries is that we have duplicate feeds... Date: Tue, 19 Apr 2005 14:59:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVEuYrnhf+VxbgkQcy8c7cIkTMWbgARbiMQ In-Reply-To: <4264BD9D.4050204@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3JIxTjT039336 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > I'm going to think about it some more but atm I'm not sure what you're > proposing helps against DOS. My proposal says that things are considered the same only if found in the same feed. This is, I believe, the only way to prevent someone from maliciously erasing someone else's entries with a blocking entry having the same ID as the entry under attack. Admittedly, the approach will lead to a number of false negatives in comparisons if people do not consistently publish "self" links when they build synthetic feeds. The only way I can see to improve on this situation is to support the "rel='superset'" link that I discussed earlier. If the superset relationship can, in fact, be expressed, the rule would change to: atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values unless each such entry contains an atom:source element which is different from that of any of the other entries with which the entry shares identical atom:id values. Two atom:source elements MUST only be considered different if they each contain an atom:link element with a rel value of "self" which identifies different feed URIs and neither of the feeds identified is known to be a 'superset' of the other feed. A superset feed is identified in a subset feed by a link element with rel value of "superset". Synthetic feed generators and aggregators MAY use other sources of information, public or private, to determine the relationships between feeds. If two atom:feed elements have identical atom:id values yet only one of them has an atom:source element with a rel value of "self", that element which contains the atom:source element with rel value of "self" SHOULD be preferred over the other. bob wyman From owner-atom-syntax@mail.imc.org Tue Apr 19 15:43:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13602 for ; Tue, 19 Apr 2005 15:43:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JJc9OA046813; Tue, 19 Apr 2005 12:38:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JJc9RV046812; Tue, 19 Apr 2005 12:38:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JJc9Pb046803 for ; Tue, 19 Apr 2005 12:38:09 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12867; Tue, 19 Apr 2005 15:38:06 -0400 (EDT) Message-Id: <200504191938.PAA12867@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: atom-syntax@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-atompub-format-08.txt Date: Tue, 19 Apr 2005 15:38:06 -0400 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : The Atom Syndication Format Author(s) : M. Nottingham, R. Sayre Filename : draft-ietf-atompub-format-08.txt Pages : 51 Date : 2005-4-19 This document specifies Atom, an XML-based Web content and metadata syndication format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-atompub-format-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-atompub-format-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-19154228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-atompub-format-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-atompub-format-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-19154228.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-atom-syntax@mail.imc.org Tue Apr 19 15:50:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14924 for ; Tue, 19 Apr 2005 15:50:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JJgvp8047539; Tue, 19 Apr 2005 12:42:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JJgvF9047538; Tue, 19 Apr 2005 12:42:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JJgvYu047514 for ; Tue, 19 Apr 2005 12:42:57 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc12) with SMTP id <2005041919425101400nre0ce>; Tue, 19 Apr 2005 19:42:51 +0000 Date: Tue, 19 Apr 2005 13:42:50 -0600 Subject: Re: One reason we have duplicates entries is that we have duplicate feeds... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <200504191859.CZI81194@ms8.netsolmail.com> Message-Id: <368C7862-B10B-11D9-83FE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3JJgvYu047533 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tuesday, April 19, 2005, at 12:59 PM, Bob Wyman wrote: > Bill de hÓra wrote: >> I'm going to think about it some more but atm I'm not sure what you're >> proposing helps against DOS. > My proposal says that things are considered the same only if found > in the same feed. This is, I believe, the only way to prevent someone > from > maliciously erasing someone else's entries with a blocking entry > having the > same ID as the entry under attack. Admittedly, the approach will lead > to a > number of false negatives in comparisons if people do not consistently > publish "self" links when they build synthetic feeds. The only way I > can see > to improve on this situation is to support the "rel='superset'" link > that I > discussed earlier. If the superset relationship can, in fact, be > expressed, > the rule would change to: > > atom:feed elements MUST NOT contain atom:entry elements with identical > atom:id values unless each such entry contains an atom:source element > which > is different from that of any of the other entries with which the entry > shares identical atom:id values. > Two atom:source elements MUST only be considered different if they each > contain an atom:link element with a rel value of "self" which > identifies > different feed URIs and neither of the feeds identified is known to be > a > 'superset' of the other feed. A superset feed is identified in a > subset feed > by a link element with rel value of "superset". Synthetic feed > generators > and aggregators MAY use other sources of information, public or > private, to > determine the relationships between feeds. > If two atom:feed elements have identical atom:id values yet only one > of them > has an atom:source element with a rel value of "self", that element > which > contains the atom:source element with rel value of "self" SHOULD be > preferred over the other. This illustrates the superiority of "self" links over atom:id in identifying a feed. If one were to attempt to use atom:id the way Bob is proposing to use a "self" link above to protect again DOS attacks, it wouldn't help (or could be easily circumvented), because there's no way to resolve disputes between feeds claiming the same atom:id. But it's easy to verify whether a feed is really the owner of it's "self" link. There would still be an attack vector, where one would use the atom:id of an entry that had left the legitimate feed's sliding window. Anyone subscribed directly to both would be protected if their feed, reader were to ignore all entries claiming to be from other feeds to which they are subscribed. But those receiving the legitimate entry via an aggregator that didn't do that or wasn't subscribed to both sources might still have trouble resolving conflicts. Of course, a feed may move over time, so atom:feed/atom:id is useful, but really only as a hint that feeds found at two locations might be the same. ...which reminds me of PaceFeedIdOrSelf, PaceFeedIdOrAlternate and PaceCoConstraintsAreBad. Out of curiosity, are these actually going to be considered at some point in the process, or is it just too late? From owner-atom-syntax@mail.imc.org Tue Apr 19 16:19:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23269 for ; Tue, 19 Apr 2005 16:19:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JK3sHJ053039; Tue, 19 Apr 2005 13:03:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JK3ssn053038; Tue, 19 Apr 2005 13:03:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JK3rRC053023 for ; Tue, 19 Apr 2005 13:03:53 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.3]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DNywo-0007TG-00 for atom-syntax@imc.org; Tue, 19 Apr 2005 20:03:50 +0000 Message-ID: <42656427.5080709@franklinmint.fm> Date: Tue, 19 Apr 2005 16:03:51 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: I-D ACTION:draft-ietf-atompub-format-08.txt References: <200504191938.PAA12867@ietf.org> In-Reply-To: <200504191938.PAA12867@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit All, HTML: http://atompub.org/2005/04/18/draft-ietf-atompub-format-08.html diffs: http://atompub.org/2005/04/18/draft-ietf-atompub-format-08-from-7.diff.html 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 Syndication Format > Author(s) : M. Nottingham, R. Sayre > Filename : draft-ietf-atompub-format-08.txt > Pages : 51 > Date : 2005-4-19 > > This document specifies Atom, an XML-based Web content and metadata > syndication format. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 19 16:29:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24056 for ; Tue, 19 Apr 2005 16:29:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JKIW13056183; Tue, 19 Apr 2005 13:18:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JKIWZL056182; Tue, 19 Apr 2005 13:18:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JKIVak056155 for ; Tue, 19 Apr 2005 13:18:31 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc14) with SMTP id <2005041920182501400hag94e>; Tue, 19 Apr 2005 20:18:25 +0000 Date: Tue, 19 Apr 2005 14:18:23 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceXmlContentWrapper From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit It may be too late, but either way, I'd like to get this into concrete form. Does anyone think this is worse than requiring the xhtml:div? Better? http://www.intertwingly.net/wiki/pie/PaceXmlContentWrapper == Abstract == Replace the requirement for an xhtml:div wrapper for content[type="xhmtl"] with an optional attribute to indicate whether the top level element of XML content is a disposable wrapper or part of the content. == Rationale == * When embedding XML in XML, the inner XML content is often wrapped in an extra element from the content's namespace in order to provide a place to declare the inner XML's namespace (whether making it the default namespace or not). * Unless there is a method to specify whether such a wrapper element has been added to the inner content, the status of the outer element of the inner content is ambiguous. Is it part of the content, or not? * In requiring a wrapper div for XHTML content, the current draft resolves this question only for XHTML content. * ...and it resolves it by a method to which a number of people object. * This proposal creates an alternative method which would work for all XML content types, and which only requires adding to the feed when action (disposing of the wrapper, or otherwise recognizing that it's not part of the content) is required. == Proposal == Add the following under section 3.1: 3.1.2 The "wrapper" Attribute Text constructs MAY have a "wrapper" attribute if the value of the "type" attribute is "xhtml". When present, the value MUST be one of "none" or "dispose". If the "wrapper" attribute is not provided, Atom Processors MUST behave as though it were present with a value of "none". If the value is "dispose", the Text construct MUST have a single element child, which Atom Processors MUST treat as a disposable wrapper for the XHTML content, and not as part of the content itself. If the value is "none", Atom Processors MUST NOT treat any element children of the Text construct as disposable wrapper elements. Add the following under section 4.1.3: 4.1.3.2 The "wrapper" Attribute The atom:content element MAY have a "wrapper" attribute if the value of the "type" attribute is "xhtml" or a MIME media type ending in "/xml" or "+xml". When present, the value MUST be one of "none" or "dispose". If the "wrapper" attribute is not provided, Atom Processors MUST behave as though it were present with a value of "none". If the value is "dispose", atom:content MUST have a single element child, which Atom Processors MUST treat as a disposable wrapper for the content, and not as part of the content itself. If the value is "none", Atom Processors MUST NOT treat any element children of atom:content as disposable wrapper elements. Remove the requirement for an XHTML div from sections 3.1.1.3 and 4.1.3.3, item 3, and adjust the example feeds as appropriate. == Impacts == Publishing tools now using wrapper elements would need to add an attribute to the containing elements, and consumers would need to key their treatment of the outermost element in XML content off it's value. == Notes == * "wrapper" could be "container" or some such thing. * The attribute could be allowed regardless of the value of @type, but only be meaninful if @type indicates an XML type. From owner-atom-syntax@mail.imc.org Tue Apr 19 16:29:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24078 for ; Tue, 19 Apr 2005 16:29:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JKFr9F055761; Tue, 19 Apr 2005 13:15:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JKFrsn055760; Tue, 19 Apr 2005 13:15:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3JKFqa1055744 for ; Tue, 19 Apr 2005 13:15:52 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 57800 messnum 6387265 invoked from network[83.70.217.193/unknown]); 19 Apr 2005 20:15:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail00.svc.cra.dublin.eircom.net (qp 57800) with SMTP; 19 Apr 2005 20:15:46 -0000 Message-ID: <426566EF.2060305@dehora.net> Date: Tue, 19 Apr 2005 21:15:43 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: I-D ACTION:draft-ietf-atompub-format-08.txt References: <200504191938.PAA12867@ietf.org> <42656427.5080709@franklinmint.fm> In-Reply-To: <42656427.5080709@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > All, > > HTML: > http://atompub.org/2005/04/18/draft-ietf-atompub-format-08.html > > diffs: > http://atompub.org/2005/04/18/draft-ietf-atompub-format-08-from-7.diff.html I was about to ask for the html, thanks :) cheers Bill From owner-atom-syntax@mail.imc.org Tue Apr 19 17:30:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28611 for ; Tue, 19 Apr 2005 17:30:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JLMqL7067077; Tue, 19 Apr 2005 14:22:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JLMq6m067076; Tue, 19 Apr 2005 14:22:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JLMolV067059 for ; Tue, 19 Apr 2005 14:22:51 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.58.240]) by smtp.cegetel.net (Postfix) with ESMTP id BD93F3182E4; Tue, 19 Apr 2005 23:22:44 +0200 (CEST) Message-ID: <426576A6.10101@cegetel.net> Date: Tue, 19 Apr 2005 23:22:46 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: PaceXmlContentWrapper References: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> In-Reply-To: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > It may be too late, but either way, I'd like to get this into concrete > form. Does anyone think this is worse than requiring the xhtml:div? > Better? > > http://www.intertwingly.net/wiki/pie/PaceXmlContentWrapper Definitely better! +1 for me -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue Apr 19 17:40:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29065 for ; Tue, 19 Apr 2005 17:40:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JLXeYA067885; Tue, 19 Apr 2005 14:33:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JLXelK067884; Tue, 19 Apr 2005 14:33:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JLXdN6067865 for ; Tue, 19 Apr 2005 14:33:40 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.58.240]) by smtp.cegetel.net (Postfix) with ESMTP id 5150731814F for ; Tue, 19 Apr 2005 23:33:34 +0200 (CEST) Message-ID: <42657932.3090505@cegetel.net> Date: Tue, 19 Apr 2005 23:33:38 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: typo in Text Constructs XHTML content? [was: I-D ACTION:draft-ietf-atompub-format-08.txt] References: <200504191938.PAA12867@ietf.org> <42656427.5080709@franklinmint.fm> In-Reply-To: <42656427.5080709@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Internet-Drafts@ietf.org wrote: >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt In section 3.1.1.3 [ Escaped characters, such as "&" and ">", represent those characters, not markup. ] Shouldn't these "characters" be written as "&" and "<"? I also propose using < instead of >, as > isn't really a problem. [ Escaped characters, such as "&" and "<", represent those characters (namely "&" and "<"), not markup. ] -- Thomas Broyer From owner-atom-syntax@mail.imc.org Tue Apr 19 17:48:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29617 for ; Tue, 19 Apr 2005 17:48:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JLfred069154; Tue, 19 Apr 2005 14:41:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JLfrX6069153; Tue, 19 Apr 2005 14:41:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JLfqku069146 for ; Tue, 19 Apr 2005 14:41:52 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j3JLfjeB002924; Tue, 19 Apr 2005 17:41:46 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CZJ41170 (AUTH bob@wyman.us); Tue, 19 Apr 2005 17:41:39 -0400 (EDT) Message-Id: <200504192141.CZJ41170@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Graham'" , "'Henry Story'" Cc: "'atom-syntax Syntax''" Subject: RE: call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds... Date: Tue, 19 Apr 2005 17:41:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVFCZZiSCyO3mzKTaWM4ujqSVHWewAHdmzQ In-Reply-To: <11207e72be5ebaf83b63e4661e5fec30@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > I'm in favour of allowing duplicate ids when the source-id is different +1 This is essentially what I was trying to get at with the horribly tortured language that I recently proposed. Clearly, I support Graham's suggestion and hope that someone with better skill at the language can figure out how to write this into the spec. Note: At PubSub, we expect to ensure that every entry we publish once we move to Atom V1.0 will contain an atom:source with a "self" link. bob wyman -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Graham Sent: Tuesday, April 19, 2005 12:30 PM To: Henry Story Cc: atom-syntax Syntax' Subject: Re: call for a vote - was: One reason we have duplicates entries is that we have duplicate feeds... I'm in favour of allowing duplicate ids when the source-id is different to simplify creating merged feeds, which would allow the client to figure out what to do. Under any other circumstance, definitely not. Graham From owner-atom-syntax@mail.imc.org Tue Apr 19 18:29:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03474 for ; Tue, 19 Apr 2005 18:29:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JMM8j1075408; Tue, 19 Apr 2005 15:22:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JMM8Cp075407; Tue, 19 Apr 2005 15:22:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JMM7Ms075393 for ; Tue, 19 Apr 2005 15:22:08 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:51269 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228704AbVDSWWG (ORCPT ); Wed, 20 Apr 2005 01:22:06 +0300 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <86e457449ca9d10a9d38c4b7c4a63f2d@iki.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Atom Syntax From: Henri Sivonen Subject: Standalone schema? Date: Wed, 20 Apr 2005 01:21:50 +0300 X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Is the Relax NG schema from the appendix hosted as a standalone HTTP resource somewhere on atompub.org ? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Tue Apr 19 18:37:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03963 for ; Tue, 19 Apr 2005 18:37:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JMTGMP077558; Tue, 19 Apr 2005 15:29:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3JMTGbv077557; Tue, 19 Apr 2005 15:29:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3JMTFgc077551 for ; Tue, 19 Apr 2005 15:29:16 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DO1DT-0000tb-O6; Tue, 19 Apr 2005 22:29:11 +0000 Message-ID: <42658639.1090805@franklinmint.fm> Date: Tue, 19 Apr 2005 18:29:13 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henri Sivonen CC: Atom Syntax Subject: Re: Standalone schema? References: <86e457449ca9d10a9d38c4b7c4a63f2d@iki.fi> In-Reply-To: <86e457449ca9d10a9d38c4b7c4a63f2d@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henri Sivonen wrote: > > Is the Relax NG schema from the appendix hosted as a standalone HTTP > resource somewhere on atompub.org ? Now it is. http://atompub.org/2005/04/18/atom.rnc Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 19 20:17:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09910 for ; Tue, 19 Apr 2005 20:17:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K08JUo018700; Tue, 19 Apr 2005 17:08:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K08JDp018699; Tue, 19 Apr 2005 17:08:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K08IJs018598 for ; Tue, 19 Apr 2005 17:08:19 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so5965wri for ; Tue, 19 Apr 2005 17:08:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eIVr84abnjP+o5LFUOwPFUzdiJKdM5p9LuPO4zkiWsd6LU3/S/9cYvXfUK7Ccr35UnlqNykKZQ8QkEr5bDTkbW4+qwM3T5nVc/MhX+Fm7glDFvSHl/Z2jQeXj3imouRw/8jyFL20hkYPpojfYOCzmObZVA/bnHQIlEGiA/NlacY= Received: by 10.54.21.37 with SMTP id 37mr1723876wru; Tue, 19 Apr 2005 17:08:12 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Tue, 19 Apr 2005 17:08:12 -0700 (PDT) Message-ID: <540e3732050419170868876523@mail.gmail.com> Date: Tue, 19 Apr 2005 19:08:12 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax@imc.org Subject: Re: PaceXmlContentWrapper In-Reply-To: <426576A6.10101@cegetel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> <426576A6.10101@cegetel.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3K08JJs018685 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -1 for me. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Tue Apr 19 22:29:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18287 for ; Tue, 19 Apr 2005 22:29:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K2Lqxo063798; Tue, 19 Apr 2005 19:21:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K2Lqgg063797; Tue, 19 Apr 2005 19:21:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K2Lp0c063788 for ; Tue, 19 Apr 2005 19:21:51 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3K2LWDA017437; Wed, 20 Apr 2005 03:21:38 +0100 (BST) In-Reply-To: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> References: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <43e42d4ba448f0fc473e2f06420d8c77@mac.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: PaceXmlContentWrapper Date: Wed, 20 Apr 2005 03:21:31 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I don't see the point of this. The problem Sam discussed can be solved without it and without requiring the div. Death to "the div is not part of the content". i) Encourage xhtml users to wrap content in a div ii) Require that they before adding any wrapper, they check whether there already is one, and use that instead. This prevents telescoping divs. I'd also request this: iii) Require that xhtml and *xml content elements have only a single child node. That is, all xml must be wrapped in an enclosing element (eg text bold more text would be invalid). Graham From owner-atom-syntax@mail.imc.org Tue Apr 19 23:22:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21162 for ; Tue, 19 Apr 2005 23:22:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K3CkqG077917; Tue, 19 Apr 2005 20:12:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K3Ckuj077916; Tue, 19 Apr 2005 20:12:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from md2.mail.umd.edu (IDENT:mirapoint@md2.mail.umd.edu [128.8.31.175]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K3Cj9J077909 for ; Tue, 19 Apr 2005 20:12:45 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) by md2.mail.umd.edu (MOS 3.5.6-GR) with ESMTP id AGG09319 (AUTH atrus); Tue, 19 Apr 2005 23:14:03 -0400 (EDT) Message-ID: <4265C944.6000704@atrus.org> Date: Tue, 19 Apr 2005 23:15:16 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: NoIndex, again X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, I've recently ended up in argument about what to do with feeds that don't want to be reproduced. I e-mailed Dave Winer in the hope of getting some information about RSS end of things. That resulted in a blog entry with interesting comments [1], and I now know that Creative Commons has an RDF schema for describing licensing [2]. The only common feature I want to include, and haven't found, is the "noindex" type of behavior (do not include in search engines). I searched the archives of this list and found an old thread discussing this very issue [3]. It seems to have fizzled out and I haven't found anything more recent documents or discussions. Was the issue simply forgotten or purposfully dropped? In the RSS discussion, it was suggested by Roger Benningfield that search eninges and syndication sites use atom:summary instead of atom:content to avoid the noarchive issue. The rationale is that summaries are meant to be reproduced, much like an abstract for a paper. I'm not sure about nofollow, I think noindex is definitely needed. The latter could be used to opt-out of services such as Feedster, Technorati, and PubSub. Thoughts and comments? [1] http://www.reallysimplesyndication.com/2005/04/19#a445 [2] http://web.resource.org/cc/ [3] http://www.imc.org/atom-syntax/mail-archive/msg00183.html Regards, -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Tue Apr 19 23:38:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22070 for ; Tue, 19 Apr 2005 23:38:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K3WYia082128; Tue, 19 Apr 2005 20:32:34 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K3WYcT082127; Tue, 19 Apr 2005 20:32:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K3WXNN082111 for ; Tue, 19 Apr 2005 20:32:34 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc11) with SMTP id <20050420033227011004bld4e>; Wed, 20 Apr 2005 03:32:28 +0000 Date: Tue, 19 Apr 2005 21:32:26 -0600 Subject: Re: NoIndex, again Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <4265C944.6000704@atrus.org> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I believe we decided not to address licensing in the Atom core because the probability of not getting it quite right is too high, especially given the differences between laws in various jurisdictions around the world. Having something in the core might require consuming applications to enforce licensing terms or make their authors liable in some jurisdictions, and we didn't want to create that rat's nest. On Tuesday, April 19, 2005, at 09:15 PM, Nikolas 'Atrus' Coukouma wrote: > > Hi, > I've recently ended up in argument about what to do with feeds that > don't want to be reproduced. I e-mailed Dave Winer in the hope of > getting some information about RSS end of things. That resulted in a > blog entry with interesting comments [1], and I now know that Creative > Commons has an RDF schema for describing licensing [2]. > > The only common feature I want to include, and haven't found, is the > "noindex" type of behavior (do not include in search engines). I > searched the archives of this list and found an old thread discussing > this very issue [3]. It seems to have fizzled out and I haven't found > anything more recent documents or discussions. > > Was the issue simply forgotten or purposfully dropped? > > In the RSS discussion, it was suggested by Roger Benningfield that > search eninges and syndication sites use atom:summary instead of > atom:content to avoid the noarchive issue. The rationale is that > summaries are meant to be reproduced, much like an abstract for a > paper. > > I'm not sure about nofollow, I think noindex is definitely needed. The > latter could be used to opt-out of services such as Feedster, > Technorati, and PubSub. > > Thoughts and comments? > > [1] http://www.reallysimplesyndication.com/2005/04/19#a445 > [2] http://web.resource.org/cc/ > [3] http://www.imc.org/atom-syntax/mail-archive/msg00183.html > > Regards, > -Nikolas 'Atrus' Coukouma > From owner-atom-syntax@mail.imc.org Tue Apr 19 23:55:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23205 for ; Tue, 19 Apr 2005 23:55:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K3ldgL085198; Tue, 19 Apr 2005 20:47:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K3ldTE085197; Tue, 19 Apr 2005 20:47:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from md0.mail.umd.edu (IDENT:mirapoint@md0.mail.umd.edu [128.8.31.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K3ldNV085190 for ; Tue, 19 Apr 2005 20:47:39 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) by md0.mail.umd.edu (MOS 3.5.6-GR) with ESMTP id AVI15520 (AUTH atrus); Tue, 19 Apr 2005 23:47:38 -0400 (EDT) Message-ID: <4265D173.5080604@atrus.org> Date: Tue, 19 Apr 2005 23:50:11 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: NoIndex, again References: In-Reply-To: X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Some pertinent quotes from the discussion two years ago: The issue of bots can be deconstructed into privacy considerations (how to specify what information should not be retained or used), rights control (how to restrict ways in which the content can be used), and resource use (how to specify the optimal access pattern). It might be benefitial to analyze each issue separately. -Misha Dynin I think while all three are valid issues, here we should limit ourselves to the first element only - replicating the meta tag behavior so that the feed has a way to tell search sites what they should and should not do with its contents. Rights control, in my opinion, is best handled with some kind of Creative Commons metadata. Resource use ties in to the ongoing thread about manifests vs. full-content feeds, so is probably best discussed in that thread. -Maciej Ceglowski And that's where the thread ends. I agree that rights control is definitely something best handled by licensing data from some other namespace (like the Creative Commons one). I'm not sure what happened with the resource use part and it's not a concern of mine (at least not for this). The first issue (privacy considerations), which a few people expressed interest in addressing, never was handled to my knowledge. If it was in some other thread, I'd appreciate a pointer in that direction. Regards, -Nikolas 'Atrus' Coukouma Antone Roundy wrote: > > I believe we decided not to address licensing in the Atom core because > the probability of not getting it quite right is too high, especially > given the differences between laws in various jurisdictions around the > world. Having something in the core might require consuming > applications to enforce licensing terms or make their authors liable > in some jurisdictions, and we didn't want to create that rat's nest. > > On Tuesday, April 19, 2005, at 09:15 PM, Nikolas 'Atrus' Coukouma wrote: > >> >> Hi, >> I've recently ended up in argument about what to do with feeds that >> don't want to be reproduced. I e-mailed Dave Winer in the hope of >> getting some information about RSS end of things. That resulted in a >> blog entry with interesting comments [1], and I now know that Creative >> Commons has an RDF schema for describing licensing [2]. >> >> The only common feature I want to include, and haven't found, is the >> "noindex" type of behavior (do not include in search engines). I >> searched the archives of this list and found an old thread discussing >> this very issue [3]. It seems to have fizzled out and I haven't found >> anything more recent documents or discussions. >> >> Was the issue simply forgotten or purposfully dropped? >> >> In the RSS discussion, it was suggested by Roger Benningfield that >> search eninges and syndication sites use atom:summary instead of >> atom:content to avoid the noarchive issue. The rationale is that >> summaries are meant to be reproduced, much like an abstract for a paper. >> >> I'm not sure about nofollow, I think noindex is definitely needed. The >> latter could be used to opt-out of services such as Feedster, >> Technorati, and PubSub. >> >> Thoughts and comments? >> >> [1] http://www.reallysimplesyndication.com/2005/04/19#a445 >> [2] http://web.resource.org/cc/ >> [3] http://www.imc.org/atom-syntax/mail-archive/msg00183.html >> >> Regards, >> -Nikolas 'Atrus' Coukouma > From owner-atom-syntax@mail.imc.org Tue Apr 19 23:56:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23243 for ; Tue, 19 Apr 2005 23:56:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K3lisW085231; Tue, 19 Apr 2005 20:47:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K3liVc085230; Tue, 19 Apr 2005 20:47:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from md2.mail.umd.edu (IDENT:mirapoint@md2.mail.umd.edu [128.8.31.175]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K3liDi085224 for ; Tue, 19 Apr 2005 20:47:44 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) by md2.mail.umd.edu (MOS 3.5.6-GR) with ESMTP id AGG12827 (AUTH atrus); Tue, 19 Apr 2005 23:49:02 -0400 (EDT) Message-ID: <4265D178.2050506@atrus.org> Date: Tue, 19 Apr 2005 23:50:16 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: NoIndex, again References: <4265C944.6000704@atrus.org> <6.1.2.0.2.20050419232752.060b8440@www.gosmalltalk.com> In-Reply-To: <6.1.2.0.2.20050419232752.060b8440@www.gosmalltalk.com> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The problem I'm having is with LiveJournal. They have 6.8 million registered users, with 2.7 million active. We're talking about a robots.txt of hundreds of megabytes. I imagine other blog hosting sites (Blogger, Xanga) have a similar problem. Also, robots.txt can only handle noindex. What about nofollow? Is nofollow needed? Is the summary/content recommendation sufficient to handle noarchive and nosnippet? Regards, -Nikolas 'Atrus' Coukouma James Robertson wrote: > robots.txt solved this problem a long time ago > > At 11:15 PM 4/19/2005, you wrote: > >> Hi, >> I've recently ended up in argument about what to do with feeds that >> don't want to be reproduced. I e-mailed Dave Winer in the hope of >> getting some information about RSS end of things. That resulted in a >> blog entry with interesting comments [1], and I now know that Creative >> Commons has an RDF schema for describing licensing [2]. >> >> The only common feature I want to include, and haven't found, is the >> "noindex" type of behavior (do not include in search engines). I >> searched the archives of this list and found an old thread discussing >> this very issue [3]. It seems to have fizzled out and I haven't found >> anything more recent documents or discussions. >> >> Was the issue simply forgotten or purposfully dropped? >> >> In the RSS discussion, it was suggested by Roger Benningfield that >> search eninges and syndication sites use atom:summary instead of >> atom:content to avoid the noarchive issue. The rationale is that >> summaries are meant to be reproduced, much like an abstract for a paper. >> >> I'm not sure about nofollow, I think noindex is definitely needed. The >> latter could be used to opt-out of services such as Feedster, >> Technorati, and PubSub. >> >> Thoughts and comments? >> >> [1] http://www.reallysimplesyndication.com/2005/04/19#a445 >> [2] http://web.resource.org/cc/ >> [3] http://www.imc.org/atom-syntax/mail-archive/msg00183.html >> >> Regards, >> -Nikolas 'Atrus' Coukouma > > > > James Robertson, Product Manager, Cincom Smalltalk > http://www.cincomsmalltalk.com/blog/blogView > From owner-atom-syntax@mail.imc.org Wed Apr 20 01:18:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27858 for ; Wed, 20 Apr 2005 01:18:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K59EE5004620; Tue, 19 Apr 2005 22:09:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K59EF3004619; Tue, 19 Apr 2005 22:09:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K59DJ9004561 for ; Tue, 19 Apr 2005 22:09:13 -0700 (PDT) (envelope-from jpanzer@aol.net) Received: from c0a80106.tipt.aol.com (sera-10-169-186-7.nscp.aoltw.net [10.169.186.7]) by mcom.com (8.10.0/8.10.0) with ESMTP id j3K595s10447; Tue, 19 Apr 2005 22:09:05 -0700 (PDT) Date: Tue, 19 Apr 2005 22:09:25 -0700 (PDT) From: "John Panzer" Subject: Re: NoIndex, again To: "Nikolas 'Atrus' Coukouma" cc: atom-syntax@imc.org In-Reply-To: <4265D173.5080604@atrus.org> Message-ID: <4265E405.9000700@aol.net> References: <4265D173.5080604@atrus.org> X-Mailer: AOL Communicator (20030925.3 Mac) 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: Regarding the privacy facet: True privacy probably requires access control, which requires authentication. In fact this is one of the major use cases for authenticated Atom feeds in AOL Journals. -John Nikolas 'Atrus' Coukouma wrote on 4/19/05, 8:50 PM: > > Some pertinent quotes from the discussion two years ago: > > The issue of bots can be deconstructed into privacy considerations > (how to specify what information should not be retained or used), > rights control (how to restrict ways in which the content can be used), > and resource use (how to specify the optimal access pattern). > It might be benefitial to analyze each issue separately. > -Misha Dynin > > > I think while all three are valid issues, here we should limit ourselves > to the first element only - replicating the meta tag behavior so that > the feed has a way to tell search sites what they should and should not > do with its contents. > > Rights control, in my opinion, is best handled with some kind of > Creative Commons metadata. Resource use ties in to the ongoing thread > about manifests vs. full-content feeds, so is probably best discussed in > that thread. > -Maciej Ceglowski > > > And that's where the thread ends. I agree that rights control is > definitely something best handled by licensing data from some other > namespace (like the Creative Commons one). I'm not sure what happened > with the resource use part and it's not a concern of mine (at least not > for this). > > The first issue (privacy considerations), which a few people expressed > interest in addressing, never was handled to my knowledge. If it was in > some other thread, I'd appreciate a pointer in that direction. > > Regards, > -Nikolas 'Atrus' Coukouma > > Antone Roundy wrote: > > > > > I believe we decided not to address licensing in the Atom core because > > the probability of not getting it quite right is too high, especially > > given the differences between laws in various jurisdictions around the > > world. Having something in the core might require consuming > > applications to enforce licensing terms or make their authors liable > > in some jurisdictions, and we didn't want to create that rat's nest. > > > > On Tuesday, April 19, 2005, at 09:15 PM, Nikolas 'Atrus' Coukouma > wrote: > > > >> > >> Hi, > >> I've recently ended up in argument about what to do with feeds that > >> don't want to be reproduced. I e-mailed Dave Winer in the hope of > >> getting some information about RSS end of things. That resulted in a > >> blog entry with interesting comments [1], and I now know that Creative > >> Commons has an RDF schema for describing licensing [2]. > >> > >> The only common feature I want to include, and haven't found, is the > >> "noindex" type of behavior (do not include in search engines). I > >> searched the archives of this list and found an old thread discussing > >> this very issue [3]. It seems to have fizzled out and I haven't found > >> anything more recent documents or discussions. > >> > >> Was the issue simply forgotten or purposfully dropped? > >> > >> In the RSS discussion, it was suggested by Roger Benningfield that > >> search eninges and syndication sites use atom:summary instead of > >> atom:content to avoid the noarchive issue. The rationale is that > >> summaries are meant to be reproduced, much like an abstract for a > paper. > >> > >> I'm not sure about nofollow, I think noindex is definitely needed. The > >> latter could be used to opt-out of services such as Feedster, > >> Technorati, and PubSub. > >> > >> Thoughts and comments? > >> > >> [1] http://www.reallysimplesyndication.com/2005/04/19#a445 > >> [2] http://web.resource.org/cc/ > >> [3] http://www.imc.org/atom-syntax/mail-archive/msg00183.html > >> > >> Regards, > >> -Nikolas 'Atrus' Coukouma > > > > From owner-atom-syntax@mail.imc.org Wed Apr 20 01:18:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27876 for ; Wed, 20 Apr 2005 01:18:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K5B4hZ005567; Tue, 19 Apr 2005 22:11:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K5B3gV005566; Tue, 19 Apr 2005 22:11:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from md2.mail.umd.edu (IDENT:mirapoint@md2.mail.umd.edu [128.8.31.175]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K5AxAW005520 for ; Tue, 19 Apr 2005 22:11:00 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) by md2.mail.umd.edu (MOS 3.5.6-GR) with ESMTP id AGG21055 (AUTH atrus); Wed, 20 Apr 2005 01:12:17 -0400 (EDT) Message-ID: <4265E4FB.10202@atrus.org> Date: Wed, 20 Apr 2005 01:13:31 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: NoIndex, again References: <4265C944.6000704@atrus.org> <6.1.2.0.2.20050419232752.060b8440@www.gosmalltalk.com> <4265CEBA.6060604@atrus.org> <6.1.2.0.2.20050419234553.0ada4408@www.gosmalltalk.com> In-Reply-To: <6.1.2.0.2.20050419234553.0ada4408@www.gosmalltalk.com> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James Robertson wrote: > At 11:38 PM 4/19/2005, you wrote: > >> The problem I'm having is with LiveJournal. They have 6.8 million >> registered users, with 2.7 million active. We're talking about a >> robots.txt of hundreds of megabytes. I imagine other blog hosting sites >> (Blogger, Xanga) have a similar problem. > > > Why would it be that big? Why wouldn't it just be a site wide policy? We offer users a choice. There's a "bot blocking" preference to address exactly this issue on LiveJournal: some users want to be in search engines, others not. The discussion two years ago mentioned the figure 25% and I'm not sure how accurate that is. When users have domains or subdomains (a paid account feature), then we do produce an appropriate robots.txt file. However, only 1.5% of users have that option available to them. I can understand if Atom doesn't want to bother with a small number of sites that have a large number of users. They are few and far between. >> Also, robots.txt can only handle noindex. What about nofollow? Is >> nofollow needed? Is the summary/content recommendation sufficient to >> handle noarchive and nosnippet? > > > well, IMHO, nofollow is pointless. I'm not a fan myself. > The rest of it? Which aggregators pay any attention? I was under the impression that this mailing list was involved in creating a standard that could then be implemented by developers. I've already mentioned JournURL's policy (from Roger Benningfield). LiveJournal has little policy in effect and it's something we are (or at least I am) trying to figure out. LiveJournal both produces feeds (RSS and Atom feeds are produced for all users) and consumes them (it acts as an aggregator via "syndication accounts"). I intend to contact some of the other large sites, but wanted to know if something already existed. I don't want re-invent the wheel and have already done a fair amount of searching for existing ones. I also don't want to just fabricate an element on my own when there's a mailing list for discussing such things. -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Wed Apr 20 01:25:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28224 for ; Wed, 20 Apr 2005 01:25:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K5Ik6s010184; Tue, 19 Apr 2005 22:18:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K5IkPV010183; Tue, 19 Apr 2005 22:18:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K5Ijo6010108 for ; Tue, 19 Apr 2005 22:18:45 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 5F7B217C for ; Tue, 19 Apr 2005 22:18:40 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j3K5IXng018748 for ; Tue, 19 Apr 2005 22:18:39 -0700 (PDT) Date: Tue, 19 Apr 2005 22:18:45 -0700 From: Walter Underwood To: atom-syntax Subject: Re: NoIndex, again Message-ID: In-Reply-To: <4265C944.6000704@atrus.org> References: <4265C944.6000704@atrus.org> X-Mailer: Mulberry/4.0.0a7 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A long time ago, I proposed a robots processing instruction that could be used in any XML format. I can find that again. An in-document robots directive is useful because it is controlled by the document author, rather than by the webmaster. "nofollow" is not particularly useful, because there is almost always another path to the document. Still, it can be a polite hint to the robot that all the links in the doc are junk. I would use exactly the model in the HTML robots meta tag, because: a) that is what robots already know how to deal with, and b) it has proven good enough. wunder --On April 19, 2005 11:15:16 PM -0400 Nikolas 'Atrus' Coukouma wrote: > > Hi, > I've recently ended up in argument about what to do with feeds that > don't want to be reproduced. I e-mailed Dave Winer in the hope of > getting some information about RSS end of things. That resulted in a > blog entry with interesting comments [1], and I now know that Creative > Commons has an RDF schema for describing licensing [2]. > > The only common feature I want to include, and haven't found, is the > "noindex" type of behavior (do not include in search engines). I > searched the archives of this list and found an old thread discussing > this very issue [3]. It seems to have fizzled out and I haven't found > anything more recent documents or discussions. > > Was the issue simply forgotten or purposfully dropped? > > In the RSS discussion, it was suggested by Roger Benningfield that > search eninges and syndication sites use atom:summary instead of > atom:content to avoid the noarchive issue. The rationale is that > summaries are meant to be reproduced, much like an abstract for a paper. > > I'm not sure about nofollow, I think noindex is definitely needed. The > latter could be used to opt-out of services such as Feedster, > Technorati, and PubSub. > > Thoughts and comments? > > [1] http://www.reallysimplesyndication.com/2005/04/19#a445 > [2] http://web.resource.org/cc/ > [3] http://www.imc.org/atom-syntax/mail-archive/msg00183.html > > Regards, > -Nikolas 'Atrus' Coukouma > > -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Wed Apr 20 01:44:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29121 for ; Wed, 20 Apr 2005 01:44:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K5ca0H024313; Tue, 19 Apr 2005 22:38:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K5ca4x024312; Tue, 19 Apr 2005 22:38:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from md2.mail.umd.edu (IDENT:mirapoint@md2.mail.umd.edu [128.8.31.175]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K5carj024294 for ; Tue, 19 Apr 2005 22:38:36 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) by md2.mail.umd.edu (MOS 3.5.6-GR) with ESMTP id AGG24152 (AUTH atrus); Wed, 20 Apr 2005 01:39:54 -0400 (EDT) Message-ID: <4265EB74.2050505@atrus.org> Date: Wed, 20 Apr 2005 01:41:08 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: atom-syntax Subject: Re: NoIndex, again References: <4265C944.6000704@atrus.org> In-Reply-To: X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: >A long time ago, I proposed a robots processing instruction that could >be used in any XML format. I can find that again. > > This seems worth resurrecting. I'd rather see the element in a seperate namespace so it 1) can be reused - most obviously, in other syndication formats, like a flavor RSS 2) is not cluttering Atom >An in-document robots directive is useful because it is controlled >by the document author, rather than by the webmaster. > >"nofollow" is not particularly useful, because there is almost always >another path to the document. Still, it can be a polite hint to the >robot that all the links in the doc are junk. > >I would use exactly the model in the HTML robots meta tag, because: >a) that is what robots already know how to deal with, and b) it has >proven good enough. > >wunder > > Speaking of reuse and HTML, in some ways I'd like to just borrow the meta tag (from the XHTML namespace), but I think it's far to generic. An element specifically for this purpose seems better. -Nikolas 'Atrus' Coukouma >--On April 19, 2005 11:15:16 PM -0400 Nikolas 'Atrus' Coukouma wrote: > > > >>Hi, >>I've recently ended up in argument about what to do with feeds that >>don't want to be reproduced. I e-mailed Dave Winer in the hope of >>getting some information about RSS end of things. That resulted in a >>blog entry with interesting comments [1], and I now know that Creative >>Commons has an RDF schema for describing licensing [2]. >> >>The only common feature I want to include, and haven't found, is the >>"noindex" type of behavior (do not include in search engines). I >>searched the archives of this list and found an old thread discussing >>this very issue [3]. It seems to have fizzled out and I haven't found >>anything more recent documents or discussions. >> >>Was the issue simply forgotten or purposfully dropped? >> >>In the RSS discussion, it was suggested by Roger Benningfield that >>search eninges and syndication sites use atom:summary instead of >>atom:content to avoid the noarchive issue. The rationale is that >>summaries are meant to be reproduced, much like an abstract for a paper. >> >>I'm not sure about nofollow, I think noindex is definitely needed. The >>latter could be used to opt-out of services such as Feedster, >>Technorati, and PubSub. >> >>Thoughts and comments? >> >>[1] http://www.reallysimplesyndication.com/2005/04/19#a445 >>[2] http://web.resource.org/cc/ >>[3] http://www.imc.org/atom-syntax/mail-archive/msg00183.html >> >>Regards, >>-Nikolas 'Atrus' Coukouma >> >> >> >> > > > >-- >Walter Underwood >Principal Architect, Verity > > > From owner-atom-syntax@mail.imc.org Wed Apr 20 02:52:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08192 for ; Wed, 20 Apr 2005 02:52:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K6idl7061928; Tue, 19 Apr 2005 23:44:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K6idDA061927; Tue, 19 Apr 2005 23:44:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from md0.mail.umd.edu (IDENT:mirapoint@md0.mail.umd.edu [128.8.31.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K6icCN061916 for ; Tue, 19 Apr 2005 23:44:38 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) by md0.mail.umd.edu (MOS 3.5.6-GR) with ESMTP id AVI36152 (AUTH atrus); Wed, 20 Apr 2005 02:44:37 -0400 (EDT) Message-ID: <4265FAEF.7080506@atrus.org> Date: Wed, 20 Apr 2005 02:47:11 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: atom-syntax Subject: Re: NoIndex, again References: <4265C944.6000704@atrus.org> <4265EB74.2050505@atrus.org> In-Reply-To: <4265EB74.2050505@atrus.org> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Nikolas 'Atrus' Coukouma wrote: >Walter Underwood wrote: > > > >>A long time ago, I proposed a robots processing instruction that could >>be used in any XML format. I can find that again. >> >> Here it is, as saved by the Wayback Machine: http://web.archive.org/web/20010407112036/http://homepages.go.com/~wunder0/robots-pi.html I'm a tad concerned that it's not namespaced, but I can't think of a way to handle that without idiosyncracies or being invalid. It also doesn't address archiving, which isn't a large concern in a syndication format. I'm not sure if it makes sense to delay archive=yes/no until mid-processing. Generally, it seems to be the right tool for the job. It should also be discussed in detail elsewhere. Unless someone has a good reason not to, let's move. >This seems worth resurrecting. I'd rather see the element in a seperate >namespace so it >1) can be reused - most obviously, in other syndication formats, like a >flavor RSS >2) is not cluttering Atom > > > >>An in-document robots directive is useful because it is controlled >>by the document author, rather than by the webmaster. >> >>"nofollow" is not particularly useful, because there is almost always >>another path to the document. Still, it can be a polite hint to the >>robot that all the links in the doc are junk. >> >>I would use exactly the model in the HTML robots meta tag, because: >>a) that is what robots already know how to deal with, and b) it has >>proven good enough. >> >>wunder >> >> >> >> >Speaking of reuse and HTML, in some ways I'd like to just borrow the >meta tag (from the XHTML namespace), but I think it's far to generic. An >element specifically for this purpose seems better. > >-Nikolas 'Atrus' Coukouma > From owner-atom-syntax@mail.imc.org Wed Apr 20 03:04:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08938 for ; Wed, 20 Apr 2005 03:04:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K6uVB1067287; Tue, 19 Apr 2005 23:56:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K6uVHR067286; Tue, 19 Apr 2005 23:56:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K6uVl5067274 for ; Tue, 19 Apr 2005 23:56:31 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j3K6uRWj015531; Wed, 20 Apr 2005 02:56:27 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CZK58727; Wed, 20 Apr 2005 02:56:26 -0400 (EDT) Message-Id: <200504200656.CZK58727@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Nikolas 'Atrus' Coukouma'" , "'atom-syntax'" Subject: RE: NoIndex, again Date: Wed, 20 Apr 2005 02:56:24 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4265C944.6000704@atrus.org> Thread-Index: AcVFWOfmXn5vQWMxQi6TAQ2v7H4X4wAFZuxw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Nikolas 'Atrus' Coukouma wrote: > I now know that Creative Commons has an RDF schema for describing > licensing We've been over this ground many times before. Read my post at: http://bobwyman.pubsub.com/main/2005/03/lazyweb_query_a.html Creative commons licenses can only be used to *grant* permissions -- not restrict them. In fact, it is violation of the Creative Commons licenses to implement systems that interpret CC licenses as prohibiting use. For example, a CC "non-commercial" license does not forbid commercial use. Rather, it simply fails to grant commercial use rights. Whether or not commercial use is permitted depends on other factors -- such as local law, etc. To claim that something like a CC "non-commercial" license prohibited the commercial use of content, you would have to argue that such use was prohibited whether or not a CC license was present. You would have to argue that NO content in RSS or Atom feeds could be used without an explicit grant via Creative Commons or some other means. The result would be a "poisoning of the stream" in that success of your assertion would instantly shut down all use of RSS and Atom feeds which did not carry Creative Commons licenses or other means of granting rights (i.e. 99.9% of all feeds.) There is a strong argument that can be made that anyone who publishes an RSS or Atom file without taking care to control access to the feed has implicitly waived their right to restrict use of the data since the usual and customary use of RSS and Atom files is to facilitate aggregation and syndication. The Digital Rights Management space is papered with hundreds of patents -- a number of which claim the use of XML to encode licenses and many which make general claims concerning methods no matter what encoding format might be used. Without evidence that someone has done a complete patent search concerning whatever methods may be proposed to control use of content (such as noindex extensions, etc.), it is unlikely that any responsible developer would risk the potential patent infringements that might result from implementing the method. > opt-out of services such as Feedster, Technorati, and PubSub. To the best of my knowledge, there is no useful means by which the services mentioned can be distinguished from any other form of aggregator. (Note: I am CTO for PubSub.com. What have you got against us?) The PubSub service, for instance, only reads RSS and Atom feeds (we do no HTML scraping) and we produce feeds *only* on behalf of specific users. (with the exception of a few "sample" feeds.) Thus, you can't distinguish what we do for our users from what individual users do for themselves with aggregators running on their own machines. (Of course, users often pay for personal aggregators while PubSub is free. Which is more commercial?) > it was suggested by Roger Benningfield that search eninges and > syndication sites use atom:summary instead of atom:content to > avoid the noarchive issue. Most feeds do not contain atom:summary elements. It is optional. This is not a useful path to a solution. In any case, reliance on atom:summary elements wouldn't help you with RSS files. If Atom has a rights issue then RSS does as well. If you want to have fine control over the use of your feeds, why don't you use a blogging system that provides such control? For instance, Yahoo!'s 360 service enables very fine control of access rights. Also, services like LiveJournal, Typepad, etc. allow you to mark your posts as "non-public" and as a result they don't get syndicated. The control you want should be provided by your blogging software -- not embedded in the Atom or RSS formats. RSS and Atom are formats for open and broad syndication. Any effort to bring DRM into this world will only result in a poisoning of the stream and a loss of the value of syndication to the millions who currently rely on it. If you really want to focus on non-individual use of your stuff, why don't you go after the sites that simply take RSS data and use it to build HTML web sites? It is entirely possible that the implicit waiver concerning content flowing through the syndication systems does not apply once the content is removed from the system. (Note: This may be a *very* important point... but is one for the lawyers, not us mere mortals.) bob wyman From owner-atom-syntax@mail.imc.org Wed Apr 20 03:45:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12314 for ; Wed, 20 Apr 2005 03:45:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K7c3DH085372; Wed, 20 Apr 2005 00:38:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K7c3RI085371; Wed, 20 Apr 2005 00:38:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K7c2te085346 for ; Wed, 20 Apr 2005 00:38:03 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:51529 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228763AbVDTHiB (ORCPT ); Wed, 20 Apr 2005 10:38:01 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <42658639.1090805@franklinmint.fm> References: <86e457449ca9d10a9d38c4b7c4a63f2d@iki.fi> <42658639.1090805@franklinmint.fm> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5c69343547da039217d73a8f46f8a87f@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: Standalone schema? Date: Wed, 20 Apr 2005 10:37:42 +0300 To: Atom Syntax X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 20, 2005, at 01:29, Robert Sayre wrote: > Henri Sivonen wrote: >> Is the Relax NG schema from the appendix hosted as a standalone HTTP >> resource somewhere on atompub.org ? > > Now it is. > > http://atompub.org/2005/04/18/atom.rnc Thanks. Could you also set the MIME type to application/vnd.relax-ng.rnc instead of text/plain? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed Apr 20 04:16:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14826 for ; Wed, 20 Apr 2005 04:16:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K85WCu099416; Wed, 20 Apr 2005 01:05:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K85WaH099415; Wed, 20 Apr 2005 01:05:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from md2.mail.umd.edu (IDENT:mirapoint@md2.mail.umd.edu [128.8.31.175]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K85V3Y099398 for ; Wed, 20 Apr 2005 01:05:32 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) by md2.mail.umd.edu (MOS 3.5.6-GR) with ESMTP id AGH02564 (AUTH atrus); Wed, 20 Apr 2005 04:06:49 -0400 (EDT) Message-ID: <42660DE4.7040906@atrus.org> Date: Wed, 20 Apr 2005 04:08:04 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: NoIndex, again References: <200504200656.CZK58727@ms8.netsolmail.com> In-Reply-To: <200504200656.CZK58727@ms8.netsolmail.com> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: >Nikolas 'Atrus' Coukouma wrote: > > >>I now know that Creative Commons has an RDF schema for describing >>licensing >> >> > We've been over this ground many times before. Read my post at: >http://bobwyman.pubsub.com/main/2005/03/lazyweb_query_a.html > > I didn't really want to discuss the licensing mess here. The previous discussion seemed to conclude that it was risky and out of scope. I just wanted to note that some attempt had been made to make a machine-readable description of licensing. > Creative commons licenses can only be used to *grant* permissions -- >not restrict them. In fact, it is violation of the Creative Commons licenses >to implement systems that interpret CC licenses as prohibiting use. For >example, a CC "non-commercial" license does not forbid commercial use. >Rather, it simply fails to grant commercial use rights. Whether or not >commercial use is permitted depends on other factors -- such as local law, >etc. > To claim that something like a CC "non-commercial" license >prohibited the commercial use of content, you would have to argue that such >use was prohibited whether or not a CC license was present. You would have >to argue that NO content in RSS or Atom feeds could be used without an >explicit grant via Creative Commons or some other means. The result would be >a "poisoning of the stream" in that success of your assertion would >instantly shut down all use of RSS and Atom feeds which did not carry >Creative Commons licenses or other means of granting rights (i.e. 99.9% of >all feeds.) > There is a strong argument that can be made that anyone who >publishes an RSS or Atom file without taking care to control access to the >feed has implicitly waived their right to restrict use of the data since the >usual and customary use of RSS and Atom files is to facilitate aggregation >and syndication. > The Digital Rights Management space is papered with hundreds of >patents -- a number of which claim the use of XML to encode licenses and >many which make general claims concerning methods no matter what encoding >format might be used. Without evidence that someone has done a complete >patent search concerning whatever methods may be proposed to control use of >content (such as noindex extensions, etc.), it is unlikely that any >responsible developer would risk the potential patent infringements that >might result from implementing the method. > > Now the /success/ of Creative Commons is debatable. I don't think anyone is going to try to implement DRM, in the usual locking sense, in a syndication feed, but maybe I'm wrong. I'm only concerned with providing guidelines to users so they have a better chance of knowing what they're doing. Thanks for pointing out the problem with even encoding licenses. I'll definitely proceed with caution, if at all. >>opt-out of services such as Feedster, Technorati, and PubSub. >> >> > To the best of my knowledge, there is no useful means by which the >services mentioned can be distinguished from any other form of aggregator. >(Note: I am CTO for PubSub.com. What have you got against us?) > I don't have anything against any of the services named, per-se. They're just some of the largest and best search engines around, and therefore the largest concerns of people trying to keep their content from being indexed (for whatever reason). > The PubSub >service, for instance, only reads RSS and Atom feeds (we do no HTML >scraping) and we produce feeds *only* on behalf of specific users. (with the >exception of a few "sample" feeds.) Thus, you can't distinguish what we do >for our users from what individual users do for themselves with aggregators >running on their own machines. (Of course, users often pay for personal >aggregators while PubSub is free. Which is more commercial?) > > The area is definitely gray (definitely a maybe?). The best difference I can come up with is that search/match services index large volumes of content and individual users never intend to read most of it. I suppose people could subscribe to 8,988,910 weblogs (number from Technorati) personally and do the same thing, but it seems absurd to compare reading 70% of entries to reading 0.000001% (if that). Similar arguments can be made with HTML search engines. Sure, you could crawl the web yourself and "view" that information, but it's unlikely you'll ever read a significant percentage of it (I'm sure specification and manual authors feel that this is true for all content) You also share the same content among all users. So do online-aggregation services. I doubt there will ever be a definitive line. I think there's a fuzzy philosophical one and you can decide which one you're on. >>it was suggested by Roger Benningfield that search eninges and >>syndication sites use atom:summary instead of atom:content to >>avoid the noarchive issue. >> >> > Most feeds do not contain atom:summary elements. It is optional. >This is not a useful path to a solution. In any case, reliance on >atom:summary elements wouldn't help you with RSS files. If Atom has a rights >issue then RSS does as well. > > I was unsatisfied with it as a solution. I think it makes a nice little guidline in the rare cases it applies to and that's about it. I've also already e-mailed Dave Winer to discuss the issue in RSS. I even cited the discussion ;) I would certainly prefer a cross-format solution and am quite happy to use Walter Underwoods' general solution for XML content (mentioned elsewhere in this tree). > If you want to have fine control over the use of your feeds, why >don't you use a blogging system that provides such control? For instance, >Yahoo!'s 360 service enables very fine control of access rights. Also, >services like LiveJournal, Typepad, etc. allow you to mark your posts as >"non-public" and as a result they don't get syndicated. The control you want >should be provided by your blogging software -- not embedded in the Atom or >RSS formats. RSS and Atom are formats for open and broad syndication. Any >effort to bring DRM into this world will only result in a poisoning of the >stream and a loss of the value of syndication to the millions who currently >rely on it. > > The point that "RSS and Atom are formats for open and broad syndication" is an excellent one and something I've pointed out often. The question was "is there any interest in providing minimal privacy elements in the spec, comprable to what HTML provides" and apparently the answer is "no." That's fine. Part of what I've been wrestling with is the question of "are RSS and Atom suited to aggregation when syndication is not desired?" LiveJournal is what I spend time working on, and there's been an argument over there about whether or not people want all of the content of all of their public posts syndicated. It's being worked on at the application level, and I wondered if there could be anything done once it's in one of these standard XML formats. The current approach is to just not put the information into a syndication-oriented format, and it seems to be the right one. > If you really want to focus on non-individual use of your stuff, why >don't you go after the sites that simply take RSS data and use it to build >HTML web sites? It is entirely possible that the implicit waiver concerning >content flowing through the syndication systems does not apply once the >content is removed from the system. (Note: This may be a *very* important >point... but is one for the lawyers, not us mere mortals.) > > I concur. I'm also looking for something that helps people find (and possibly be alerted to) copyright infringement and abuse. It's a somewhat seperate battle. My current feeling is that a "noarchive"-like element should be used to indicate that the items should not persist any longer than they do in the feed. I'm sure the issue will be explored sometime, and hopefully before things get too unpleasant. > bob wyman > -Nikolas 'Atrus' Coukouma From owner-atom-syntax@mail.imc.org Wed Apr 20 04:34:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16354 for ; Wed, 20 Apr 2005 04:34:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K8T6cP010787; Wed, 20 Apr 2005 01:29:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K8T6NZ010786; Wed, 20 Apr 2005 01:29:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K8T5nr010769 for ; Wed, 20 Apr 2005 01:29:05 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:51556 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228754AbVDTI3D (ORCPT ); Wed, 20 Apr 2005 11:29:03 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <43e42d4ba448f0fc473e2f06420d8c77@mac.com> References: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> <43e42d4ba448f0fc473e2f06420d8c77@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <33ccd84c5726cd46f46569239e46a2de@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: PaceXmlContentWrapper Date: Wed, 20 Apr 2005 11:29:00 +0300 To: atom-syntax X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 20, 2005, at 05:21, Graham wrote: > iii) Require that xhtml and *xml content elements have only a single > child node. That is, all xml must be wrapped in an enclosing element > (eg text bold more text would be invalid). -1. The Atom content element is the wrapper. If your rendering mechanism requires a single root but not atom:content, shouldn't it be your responsibility to add it? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed Apr 20 04:58:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17937 for ; Wed, 20 Apr 2005 04:58:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K8rkIs022766; Wed, 20 Apr 2005 01:53:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K8rkBx022765; Wed, 20 Apr 2005 01:53:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3K8rj6S022725 for ; Wed, 20 Apr 2005 01:53:45 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 54449 messnum 2902724 invoked from network[213.94.211.166/dev2.mcpps.com]); 20 Apr 2005 08:53:39 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail06.svc.cra.dublin.eircom.net (qp 54449) with SMTP; 20 Apr 2005 08:53:39 -0000 Message-ID: <4266188E.4040907@dehora.net> Date: Wed, 20 Apr 2005 09:53:34 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: PaceXmlContentWrapper References: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> <43e42d4ba448f0fc473e2f06420d8c77@mac.com> <33ccd84c5726cd46f46569239e46a2de@iki.fi> In-Reply-To: <33ccd84c5726cd46f46569239e46a2de@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henri Sivonen wrote: > > On Apr 20, 2005, at 05:21, Graham wrote: > >> iii) Require that xhtml and *xml content elements have only a single >> child node. That is, all xml must be wrapped in an enclosing element >> (eg text bold more text would be invalid). > > > -1. The Atom content element is the wrapper. > > If your rendering mechanism requires a single root but not atom:content, > shouldn't it be your responsibility to add it? Not if the content formats have single roots by design. cheers Bill From owner-atom-syntax@mail.imc.org Wed Apr 20 06:06:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21724 for ; Wed, 20 Apr 2005 06:06:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K9wQ75045473; Wed, 20 Apr 2005 02:58:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3K9wQtM045472; Wed, 20 Apr 2005 02:58:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3K9wPI4045427 for ; Wed, 20 Apr 2005 02:58:25 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3K9vLL9003996; Wed, 20 Apr 2005 10:57:26 +0100 (BST) In-Reply-To: <33ccd84c5726cd46f46569239e46a2de@iki.fi> References: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> <43e42d4ba448f0fc473e2f06420d8c77@mac.com> <33ccd84c5726cd46f46569239e46a2de@iki.fi> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8bb2ddd3bd1a52b6eef271899d79af4a@mac.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: PaceXmlContentWrapper Date: Wed, 20 Apr 2005 10:57:21 +0100 To: Henri Sivonen X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 20 Apr 2005, at 9:29 am, Henri Sivonen wrote: > On Apr 20, 2005, at 05:21, Graham wrote: > >> iii) Require that xhtml and *xml content elements have only a single >> child node. That is, all xml must be wrapped in an enclosing element >> (eg text bold more text would be invalid). > > -1. The Atom content element is the wrapper. > > If your rendering mechanism requires a single root but not > atom:content, shouldn't it be your responsibility to add it? You misread my intent. Requiring a single root (as the XML spec itself does) means there's always a hook available to put the namespace declaration, negating the need for ever adding an additional wrapper. Graham Parks From owner-atom-syntax@mail.imc.org Wed Apr 20 06:30:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24183 for ; Wed, 20 Apr 2005 06:30:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KAOho1058572; Wed, 20 Apr 2005 03:24:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KAOhWe058571; Wed, 20 Apr 2005 03:24:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KAOhRO058555 for ; Wed, 20 Apr 2005 03:24:43 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:51653 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228835AbVDTKYl convert rfc822-to-8bit (ORCPT ); Wed, 20 Apr 2005 13:24:41 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <4266188E.4040907@dehora.net> References: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> <43e42d4ba448f0fc473e2f06420d8c77@mac.com> <33ccd84c5726cd46f46569239e46a2de@iki.fi> <4266188E.4040907@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0d7d27794b89d498489b0708b6c54e43@iki.fi> Content-Transfer-Encoding: 8BIT From: Henri Sivonen Subject: Re: PaceXmlContentWrapper Date: Wed, 20 Apr 2005 13:24:24 +0300 To: atom-syntax Syntax X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Apr 20, 2005, at 11:53, Bill de hÓra wrote: > Henri Sivonen wrote: >> On Apr 20, 2005, at 05:21, Graham wrote: >>> iii) Require that xhtml and *xml content elements have only a single >>> child node. That is, all xml must be wrapped in an enclosing element >>> (eg text bold more text would be invalid). >> -1. The Atom content element is the wrapper. >> If your rendering mechanism requires a single root but not >> atom:content, shouldn't it be your responsibility to add it? > > Not if the content formats have single roots by design. Yes, */xml and */*+xml obviously require a single root. However, type='xhtml' is a fragment--not a full XHTML doc. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed Apr 20 10:27:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14011 for ; Wed, 20 Apr 2005 10:27:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KEFfMd059050; Wed, 20 Apr 2005 07:15:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KEFfrP059049; Wed, 20 Apr 2005 07:15:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KEFeK7059031 for ; Wed, 20 Apr 2005 07:15:41 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc13) with SMTP id <200504201415340160059th3e>; Wed, 20 Apr 2005 14:15:34 +0000 Date: Wed, 20 Apr 2005 08:15:33 -0600 Subject: Re: PaceXmlContentWrapper Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <0d7d27794b89d498489b0708b6c54e43@iki.fi> Message-Id: X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3KEFfK7059044 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wednesday, April 20, 2005, at 04:24 AM, Henri Sivonen wrote: > On Apr 20, 2005, at 11:53, Bill de hÓra wrote: > >> Henri Sivonen wrote: >>> On Apr 20, 2005, at 05:21, Graham wrote: >>>> iii) Require that xhtml and *xml content elements have only a >>>> single child node. That is, all xml must be wrapped in an enclosing >>>> element (eg text bold more text would be >>>> invalid). >>> -1. The Atom content element is the wrapper. >>> If your rendering mechanism requires a single root but not >>> atom:content, shouldn't it be your responsibility to add it? >> >> Not if the content formats have single roots by design. > > Yes, */xml and */*+xml obviously require a single root. However, > type='xhtml' is a fragment--not a full XHTML doc. > Here's the relevant spec text for */xml and */*+xml: If the value of "type" ends with "+xml" or "/xml" (case-insensitive), the content of atom:content MAY include child elements, and SHOULD be suitable for handling as the indicated media type. If the "src" attribute is not provided, this would normally mean that the "atom:content" element would contain a single child element which would serve as the root element of the XML document of the indicated type. * MAY include child elements, not MUST or even SHOULD * "this would normally mean ... a single child element which would serve as the root element of the XML document of the indicated type" -- not " MUST/SHOULD ... a single child element ..." It looks to me like fragments of other types could easily end up in there too. On Wednesday, April 20, 2005, at 03:57 AM, Graham wrote: > You misread my intent. Requiring a single root (as the XML spec itself > does) means there's always a hook available to put the namespace > declaration, negating the need for ever adding an additional wrapper. So requiring a wrapper to be added to the content when the author didn't put one there, and not providing a way to signal the author's intent is better than giving the publishing software a way to add and signal the presence of a software-generated wrapper or publish without an extra wrapper? If the only issue were the possibility of cascading wrappers, that might be so, but I for one don't agree that adding even a single wrapper is always a benign process. We certainly can't be sure of this for all future XML fragment types that might get embedded in Atom documents. From owner-atom-syntax@mail.imc.org Wed Apr 20 11:02:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17666 for ; Wed, 20 Apr 2005 11:02:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KEr1cQ064053; Wed, 20 Apr 2005 07:53:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KEr1ld064052; Wed, 20 Apr 2005 07:53:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KEr04N064046 for ; Wed, 20 Apr 2005 07:53:00 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DOGZV-0004NJ-97; Wed, 20 Apr 2005 14:52:57 +0000 Message-ID: <42666CC7.7070902@franklinmint.fm> Date: Wed, 20 Apr 2005 10:52:55 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henri Sivonen CC: Atom Syntax Subject: Re: Standalone schema? References: <86e457449ca9d10a9d38c4b7c4a63f2d@iki.fi> <42658639.1090805@franklinmint.fm> <5c69343547da039217d73a8f46f8a87f@iki.fi> In-Reply-To: <5c69343547da039217d73a8f46f8a87f@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henri Sivonen wrote: > Could you also set the MIME type to application/vnd.relax-ng.rnc instead > of text/plain? Hmm. That's not a registered type, is it? Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 20 12:40:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26041 for ; Wed, 20 Apr 2005 12:40:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KGWRYR088556; Wed, 20 Apr 2005 09:32:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KGWRr8088554; Wed, 20 Apr 2005 09:32:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [165.227.249.220] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KGWKdS088431; Wed, 20 Apr 2005 09:32:22 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4265C944.6000704@atrus.org> References: <4265C944.6000704@atrus.org> Date: Wed, 20 Apr 2005 09:32:10 -0700 To: "Nikolas 'Atrus' Coukouma" , atom-syntax From: Paul Hoffman Subject: Re: NoIndex, again Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We chose not to put things like this in the Atom core. Feel free to write an extension and discuss it here; there was certainly interest in many directions about grappling with the many intertwined issues that arise out of copyright, privacy, and so on. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Apr 20 12:41:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26091 for ; Wed, 20 Apr 2005 12:41:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KGTQXt087460; Wed, 20 Apr 2005 09:29:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KGTQkE087459; Wed, 20 Apr 2005 09:29:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KGTORe087433 for ; Wed, 20 Apr 2005 09:29:25 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:51849 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228684AbVDTQ3W (ORCPT ); Wed, 20 Apr 2005 19:29:22 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <42666CC7.7070902@franklinmint.fm> References: <86e457449ca9d10a9d38c4b7c4a63f2d@iki.fi> <42658639.1090805@franklinmint.fm> <5c69343547da039217d73a8f46f8a87f@iki.fi> <42666CC7.7070902@franklinmint.fm> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5f3b83f421fc14459ef9daf34c7cae85@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: Standalone schema? Date: Wed, 20 Apr 2005 19:29:01 +0300 To: Atom Syntax X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 20, 2005, at 17:52, Robert Sayre wrote: > Henri Sivonen wrote: > >> Could you also set the MIME type to application/vnd.relax-ng.rnc >> instead of text/plain? > > Hmm. That's not a registered type, is it? It doesn't appear in the registry. I thought that type had consensus on the OASIS Relax NG mailing list in last July, but apparently the registration has not been carried out. I guess that leaves application/octet-stream, then. :-/ (It seems to me the MIME type system is dysfunctional and extension/foo, where foo is the commonly used filename extension would go a long way for new types.) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Wed Apr 20 13:20:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29306 for ; Wed, 20 Apr 2005 13:20:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KH55VV099020; Wed, 20 Apr 2005 10:05:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KH55Yp099016; Wed, 20 Apr 2005 10:05:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KH50nc098963 for ; Wed, 20 Apr 2005 10:05:04 -0700 (PDT) (envelope-from apache@newodin.ietf.org) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DOIdI-0006Ei-6W; Wed, 20 Apr 2005 13:05:00 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'The Atom Syndication Format' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Wed, 20 Apr 2005 13:05:00 -0400 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The IESG has received a request from the Atom Publishing Format and Protocol WG to consider the following document: - 'The Atom Syndication Format ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-05-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt From owner-atom-syntax@mail.imc.org Wed Apr 20 13:40:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01062 for ; Wed, 20 Apr 2005 13:40:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KHXKAA006623; Wed, 20 Apr 2005 10:33:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KHXKkw006622; Wed, 20 Apr 2005 10:33:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KHXJGI006602 for ; Wed, 20 Apr 2005 10:33:19 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3KHWKZb013644; Wed, 20 Apr 2005 18:32:26 +0100 (BST) In-Reply-To: <42657932.3090505@cegetel.net> References: <200504191938.PAA12867@ietf.org> <42656427.5080709@franklinmint.fm> <42657932.3090505@cegetel.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: typo in Text Constructs XHTML content? [was: I-D ACTION:draft-ietf-atompub-format-08.txt] Date: Wed, 20 Apr 2005 18:32:27 +0100 To: Thomas Broyer X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 19 Apr 2005, at 10:33 pm, Thomas Broyer wrote: > In section 3.1.1.3 > [ > Escaped characters, such as "&" and ">", represent those characters, > not > markup. > ] > I also propose using < instead of >, as > isn't really a problem. > > [ > Escaped characters, such as "&" and "<", represent those > characters (namely "&" and "<"), not markup. > ] No, the current wording is technically correct but the wording could be better: The escaped versions of characters such as "&" and ">" represent those characters, not markup. Graham From owner-atom-syntax@mail.imc.org Wed Apr 20 13:49:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01820 for ; Wed, 20 Apr 2005 13:49:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KHej1L007630; Wed, 20 Apr 2005 10:40:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KHejkN007629; Wed, 20 Apr 2005 10:40:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KHeiLV007612 for ; Wed, 20 Apr 2005 10:40:45 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3KHd63J015856; Wed, 20 Apr 2005 18:39:06 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: PaceXmlContentWrapper Date: Wed, 20 Apr 2005 18:39:13 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 20 Apr 2005, at 3:15 pm, Antone Roundy wrote: > So requiring a wrapper to be added to the content when the author > didn't put one there, and not providing a way to signal the author's > intent is better than giving the publishing software a way to add and > signal the presence of a software-generated wrapper or publish without > an extra wrapper? Actually I was thinking about this and you're right, it isn't benign to an XHTML fragment into a block (by adding a div) or whatever for no reason. That put's me in favor of Sam's spec, but I currently the explanation of why and how it should work is insufficient: The XHTML div element itself MUST NOT be considered part of the content. Expanding: Note the intended content is that inside the XHTML div and so the div itself MUST be discarded. I'd like some mention one way or the other of what happens to attributes placed on the div. I presume they'd be ignored and shouldn't be used. Graham From owner-atom-syntax@mail.imc.org Wed Apr 20 13:56:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02289 for ; Wed, 20 Apr 2005 13:56:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KHoAYM008900; Wed, 20 Apr 2005 10:50:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KHoAAI008899; Wed, 20 Apr 2005 10:50:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KHo9Se008876 for ; Wed, 20 Apr 2005 10:50:10 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3KHn8DR018951; Wed, 20 Apr 2005 18:49:08 +0100 (BST) In-Reply-To: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> References: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <15d5baf3ca25bdce2a7412e7f22d6ba7@mac.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: PaceXmlContentWrapper Date: Wed, 20 Apr 2005 18:49:15 +0100 To: Antone Roundy X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just to address the Pace. I support it, but I don't think it's necessary to add it to XML data types, since "normally [this would] mean that the "atom:content" element would contain a single child element which would serve as the root element of the XML document of the indicated type", which is where you put the namespace, so you'd never need a wrapper, so we can drop the attribute and assume its value is "none". For XHTML, there's almost no reason not to add the div, so we might as well drop the attribute here and use assume its value is "dispose". Handily this means your Pace can be implemented with no changes to the current draft. Graham From owner-atom-syntax@mail.imc.org Wed Apr 20 15:01:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08210 for ; Wed, 20 Apr 2005 15:01:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KIrqfV024235; Wed, 20 Apr 2005 11:53:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KIrq57024234; Wed, 20 Apr 2005 11:53:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KIroWG024205 for ; Wed, 20 Apr 2005 11:53:51 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.66.109]) by smtp.cegetel.net (Postfix) with ESMTP id DAC8322C820; Wed, 20 Apr 2005 20:53:44 +0200 (CEST) Message-ID: <4266A53A.6010709@cegetel.net> Date: Wed, 20 Apr 2005 20:53:46 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Graham Cc: Antone Roundy , atom-syntax Subject: Re: PaceXmlContentWrapper References: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> <15d5baf3ca25bdce2a7412e7f22d6ba7@mac.com> In-Reply-To: <15d5baf3ca25bdce2a7412e7f22d6ba7@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > Just to address the Pace. I support it, but I don't think it's necessary > to add it to XML data types, since "normally [this would] mean that the > "atom:content" element would contain a single child element which would > serve as the root element of the XML document of the indicated type", > which is where you put the namespace, so you'd never need a wrapper, so > we can drop the attribute and assume its value is "none". I quite agree. > For XHTML, there's almost no reason not to add the div, so we might as > well drop the attribute here and use assume its value is "dispose". For XHTML, there's almost no reason to add a div if it's not needed or wanted by the author. I'd expect my feed and entry titles not to be block-content but rather inline content, so a div wouldn't be an appropriate container regarding its structural meaning. People wanting containers to carry their XHTML namespace declarations (in order to produce prefix-free documents) can choose among the inline-level span or the block-level div elements. If their content is already in a container (e.g. a single paragraph summary), they can use it as the xmlns holder. Moreover, not requiring a div container discards at the same time the questions such as what to do with its attributes? should we state that the div container MUST NOT have any attribute other than the XHTML namespace binding? etc. The spec could still provide examples and suggest such a use of an almost-meaningless container, without mandating it. This does not mean either that the "could validly appear within a XHTML div element" wording is to be removed! but it should apply to the Text Construct element. It could as well be more precise (using a SHOULD) depending on the text construct element, saying the atom:title element SHOULD contain XHTML text and markup that could validly appear within an XHTML span element: the span content model is a subset of the div one so this doesn't interfere with the preceding MUST. It would only be an indication of which kind of content (inline or block) is expected. I must admit I still can't understand why the div container was introduced an how it has survived 'til now... (this is NOT a criticism, just a remark; I'd be glad if someone could point me to the thread(s) where it has been discussed and adopted) -- Thomas Broyer From owner-atom-syntax@mail.imc.org Wed Apr 20 15:26:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10905 for ; Wed, 20 Apr 2005 15:26:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KJ7E0R027768; Wed, 20 Apr 2005 12:07:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KJ7EML027767; Wed, 20 Apr 2005 12:07:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KJ7D4k027758 for ; Wed, 20 Apr 2005 12:07:13 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DOKXS-0001Bd-Nh; Wed, 20 Apr 2005 19:07:06 +0000 Message-ID: <4266A85B.9010400@franklinmint.fm> Date: Wed, 20 Apr 2005 15:07:07 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Broyer CC: Graham , Antone Roundy , atom-syntax Subject: Re: PaceXmlContentWrapper References: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> <15d5baf3ca25bdce2a7412e7f22d6ba7@mac.com> <4266A53A.6010709@cegetel.net> In-Reply-To: <4266A53A.6010709@cegetel.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thomas Broyer wrote: > > I must admit I still can't understand why the div container was > introduced an how it has survived 'til now... (this is NOT a criticism, > just a remark; I'd be glad if someone could point me to the thread(s) > where it has been discussed and adopted) Take a look at the documents here: -1 to the Pace, BTW. Graham's covered the reasons. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 20 15:27:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10936 for ; Wed, 20 Apr 2005 15:27:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KJEEG5029249; Wed, 20 Apr 2005 12:14:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KJEEtF029248; Wed, 20 Apr 2005 12:14:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KJEDJQ029212 for ; Wed, 20 Apr 2005 12:14:13 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3KJDSrN014176; Wed, 20 Apr 2005 20:13:39 +0100 (BST) In-Reply-To: <4266A53A.6010709@cegetel.net> References: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> <15d5baf3ca25bdce2a7412e7f22d6ba7@mac.com> <4266A53A.6010709@cegetel.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: PaceXmlContentWrapper Date: Wed, 20 Apr 2005 20:13:37 +0100 To: Thomas Broyer X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 20 Apr 2005, at 7:53 pm, Thomas Broyer wrote: > I'd expect my feed and entry titles not to be block-content but rather > inline content, so a div wouldn't be an appropriate container > regarding its structural meaning. Let me stop you right there. The first thing to note is that the div is trivial to add and will be discarded straight away by the consumer. Therefore: - It does not change the meaning of the fragment - It is not hard to do Therefore we can conclude the cost, even to people that don't need it, is essentially zero. > People wanting containers to carry their XHTML namespace declarations > (in order to produce prefix-free documents) can choose among the > inline-level span or the block-level div elements. If their content is > already in a container (e.g. a single paragraph summary), they can use > it as the xmlns holder. This is exactly the benefit of the required and then discarded div. Without it, a significant proportion of users has to add chuff within their content that may change its meaning. Graham From owner-atom-syntax@mail.imc.org Wed Apr 20 15:55:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12934 for ; Wed, 20 Apr 2005 15:55:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KJkU0u034165; Wed, 20 Apr 2005 12:46:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KJkUGu034164; Wed, 20 Apr 2005 12:46:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KJkTj5034148 for ; Wed, 20 Apr 2005 12:46:30 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so550491wri for ; Wed, 20 Apr 2005 12:46:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rDvePbGpL+7V+q70eLyKqYJtU1nvVZhJ5G9p2Lxur5ABLuEwaUpG3JeH9+G52ZWK24b86YwxbhPW6TB0bIeh23XHd0vTICc9/TUgcOUl23mE3PGq2QEzA63QkbkNjS+H3YFWhnSb5nCudSwwOFt6sGQccY0uJS5B1GdFQhGSKl8= Received: by 10.54.49.6 with SMTP id w6mr5057958wrw; Wed, 20 Apr 2005 12:46:22 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Wed, 20 Apr 2005 12:46:21 -0700 (PDT) Message-ID: <540e373205042012466ffaf8b9@mail.gmail.com> Date: Wed, 20 Apr 2005 14:46:21 -0500 From: "Roger B." Reply-To: "Roger B." To: bob@wyman.us Subject: Re: NoIndex, again Cc: atom-syntax In-Reply-To: <200504200656.CZK58727@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4265C944.6000704@atrus.org> <200504200656.CZK58727@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3KJkUj5034159 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Most feeds do not contain atom:summary elements. It is optional. > This is not a useful path to a solution. Bob: The fact that a summary is optional is precisely why it is a useful approach. It's all about working together, taking responsibility, and operating in good faith. If a publisher provides a feed with nothing but inline atom:content, it's reasonable for me to assume that my web-based aggregator can display that content. If that publisher wants me to only display an excerpt, then it is reasonable to expect said publisher to insert an atom:summary into her feed. > In any case, reliance on > atom:summary elements wouldn't help you with RSS files. If Atom has a rights > issue then RSS does as well. There are two ways to approach the matter in RSS: (1) Rely on description/content:encoded as an analog to summary/content. (2) Evangelize the use of atom:summary within RSS. -- Roger Benningfield http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Wed Apr 20 16:48:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18643 for ; Wed, 20 Apr 2005 16:48:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KKdQOu047499; Wed, 20 Apr 2005 13:39:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KKdQVQ047498; Wed, 20 Apr 2005 13:39:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KKdPkZ047467 for ; Wed, 20 Apr 2005 13:39:26 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.66.109]) by smtp.cegetel.net (Postfix) with ESMTP id C537D22CA5F; Wed, 20 Apr 2005 22:39:19 +0200 (CEST) Message-ID: <4266BDF3.5060601@cegetel.net> Date: Wed, 20 Apr 2005 22:39:15 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Graham Cc: atom-syntax Subject: Re: PaceXmlContentWrapper References: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> <15d5baf3ca25bdce2a7412e7f22d6ba7@mac.com> <4266A53A.6010709@cegetel.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > On 20 Apr 2005, at 7:53 pm, Thomas Broyer wrote: >> People wanting containers to carry their XHTML namespace declarations >> (in order to produce prefix-free documents) can choose among the >> inline-level span or the block-level div elements. If their content is >> already in a container (e.g. a single paragraph summary), they can use >> it as the xmlns holder. > > > This is exactly the benefit of the required and then discarded div. > Without it, a significant proportion of users has to add chuff within > their content that may change its meaning. Not if: - they're suggested to use span for the title and div elsewhere, or - become aware they don't need such a container (whether it's part of the content or not) if they use prefixes (to the atom elements -even a simple "a:"-, so they don't have to modify their XHTML which is almost always served without prefix, as per the XHTML DTD and per HTML compatibility for non-supporting browsers) And since the Atom spec uses the "atom:" convention to name the elements, I think a significant proportion of users will use the same convention will find the forced div container quite "bizarre" and *really* meaningless: "what the hell have I to add a div element? moreover in my titles which I expect to inline content? well, OK, this is just a discarded container, but, well, it's not really clean to transform inline content into block content and still have it behave as inline content, isn't it?" I'm sincerely convinced people should *choose* to use a meaningless container to carry their namespace decl when they don't *want* to use prefixes and/or don't *want* to declare it elsewhere (e.g. on the atom:feed, atom:entry or atom:content). If they just imitate someone else's feed without knowing what is a div (block content) and use it for their XHTML title, they'll quickly learn that div is a block-level container that does not suit the title needs. They'll ask (themselves, Google or someone else), they'll find (use span or use prefixes) and they'll *choose*. Note to Robert: I can't find anything meaningful on the bloggerDev group about "XHTML div" or "div container"... The link you gave me points to a one-message thread where someone uses 3 embedded divs for testing, but I can't find out how it's related to this discussion... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Wed Apr 20 19:00:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03083 for ; Wed, 20 Apr 2005 19:00:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KMpepR077373; Wed, 20 Apr 2005 15:51:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KMpeKu077372; Wed, 20 Apr 2005 15:51:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KMpc2K077343 for ; Wed, 20 Apr 2005 15:51:39 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050420225132.JJUV3252.mta08-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com> for ; Wed, 20 Apr 2005 23:51:32 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050420225132.EFHV1352.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com> for ; Wed, 20 Apr 2005 23:51:32 +0100 Date: Wed, 20 Apr 2005 23:51:32 +0100 From: David Powell X-Mailer: The Bat! (v3.0.9.17 Return) Professional X-Priority: 3 (Normal) Message-ID: <435944839.20050420235132@djpowell.net> To: atom-syntax@imc.org Subject: xml:base and html rendering MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I recently tried to render a bunch of Atom entries as an HTML page and I hit a problem. I think it is probably worth mentioning now in case any implementors hadn't noticed it: Atom supports xml:base anywhere in the document, so different entries can have different base-URIs. HTML, however, doesn't support xml:base. This makes it difficult to display multiple entries on a HTML page. The only way to do it would be to attempt to rewrite the URI references in content as absolute URIs. I expect that this is extremely difficult to do reliably though. Rewriting links and image tags probably isn't too hard, but rewriting links in embedded CSS, SVG, VML, etc is a bit harder. Rewriting HTML 4.0 content using XSLT is basically impossible. Having implemented an Atom parser in XSLT as part of my Atom/RDF experiments, I tend to think that xml:base is more trouble than it is worth, and could be a barrier to interoperability given the common use case of using HTML to present entries. -- Dave From owner-atom-syntax@mail.imc.org Wed Apr 20 19:39:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08783 for ; Wed, 20 Apr 2005 19:39:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KNW5nS086543; Wed, 20 Apr 2005 16:32:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KNW545086541; Wed, 20 Apr 2005 16:32:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KNW4e7086525 for ; Wed, 20 Apr 2005 16:32:04 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DOOfn-0006mX-Nm; Wed, 20 Apr 2005 23:31:59 +0000 Message-ID: <4266E670.5000201@franklinmint.fm> Date: Wed, 20 Apr 2005 19:32:00 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Powell CC: atom-syntax@imc.org Subject: Re: xml:base and html rendering References: <435944839.20050420235132@djpowell.net> In-Reply-To: <435944839.20050420235132@djpowell.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Powell wrote: > > I recently tried to render a bunch of Atom entries as an HTML page and > I hit a problem. I think it is probably worth mentioning now in case > any implementors hadn't noticed it: > > Atom supports xml:base anywhere in the document, so different entries > can have different base-URIs. HTML, however, doesn't support xml:base. > This makes it difficult to display multiple entries on a HTML page. I think we need to update the draft and stress that (X)HTML content is not subject to xml:base processing. Only XHTML2 cites xml:base as a normative reference and the xml:base spec is crystal-clear on the matter: "The deployment of XML Base is through normative reference by new specifications, for example XLink and the XML Infoset. Applications and specifications built upon these new technologies will natively support XML Base. The behavior of xml:base attributes in applications based on specifications that do not have direct or indirect normative reference to XML Base is undefined."[0] > > Having implemented an Atom parser in XSLT as part of my Atom/RDF > experiments, I tend to think that xml:base is more trouble than it is > worth, and could be a barrier to interoperability given the common use > case of using HTML to present entries. I added xml:base support to Thunderbird's parser, but Mozilla's DOM implementation happens to support the feature already, so it was a one-liner. However, it is a DOM Level-3 feature, and I don't know how prevalent support for it is. It might also interact poorly with other parsing approachs. Feedback? Robert Sayre [0] http://www.w3.org/TR/xmlbase/ From owner-atom-syntax@mail.imc.org Wed Apr 20 19:48:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09649 for ; Wed, 20 Apr 2005 19:48:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KNg1PE088056; Wed, 20 Apr 2005 16:42:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3KNg11e088055; Wed, 20 Apr 2005 16:42:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3KNg0pt088039 for ; Wed, 20 Apr 2005 16:42:00 -0700 (PDT) (envelope-from philringnalda@gmail.com) Received: by wproxy.gmail.com with SMTP id 57so465859wri for ; Wed, 20 Apr 2005 16:41:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bBGncCzc7jY4dXJ4Qx5341WhD7OCYEiHhGoky/3Nnoqb+ljGWAmuiA5kyYRTfNoebuWTSebpDYEiY9SiQSQByraV1cjwRorQHmnIdrJWoukchgYrv+JcP1iocOCqjsJ0k0CfKzet+Mdth6W2KCW2V6AE9NcKrR+ensnJNgAsOpY= Received: by 10.54.68.7 with SMTP id q7mr1435956wra; Wed, 20 Apr 2005 16:41:52 -0700 (PDT) Received: by 10.54.83.15 with HTTP; Wed, 20 Apr 2005 16:41:52 -0700 (PDT) Message-ID: <9547bc9c05042016413b67ef08@mail.gmail.com> Date: Wed, 20 Apr 2005 16:41:52 -0700 From: Phil Ringnalda Reply-To: Phil Ringnalda To: atom-syntax@imc.org Subject: Re: xml:base and html rendering In-Reply-To: <435944839.20050420235132@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <435944839.20050420235132@djpowell.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3KNg0pt088050 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/20/05, David Powell wrote: > Atom supports xml:base anywhere in the document, so different entries > can have different base-URIs. HTML, however, doesn't support xml:base. > This makes it difficult to display multiple entries on a HTML page. Depending on your need for correctness and elegance, you can just use the ugly hack of scattering elements in your output. It isn't right, but it works in every browser I've tried, and makes me happier than having relative URIs resolved relative to where my online aggregator's running. Phil Ringnalda From owner-atom-syntax@mail.imc.org Wed Apr 20 21:17:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17060 for ; Wed, 20 Apr 2005 21:17:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3L14ZEi004412; Wed, 20 Apr 2005 18:04:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3L14ZMX004411; Wed, 20 Apr 2005 18:04:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3L14XvS004385 for ; Wed, 20 Apr 2005 18:04:34 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IF90095KUPYW380@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Thu, 21 Apr 2005 02:58:46 +0200 (CEST) Received: from quark ([80.203.88.140]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IF9002T4V1ARB10@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Thu, 21 Apr 2005 03:05:34 +0200 (CEST) Date: Thu, 21 Apr 2005 03:07:31 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: PaceXmlContentWrapper In-reply-to: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> To: Antone Roundy , atom-syntax@imc.org Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <2E0B7B10-B110-11D9-83FE-003065EA6144@geckotribe.com> User-Agent: Opera M2/8.0 (Win32, build 7561) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Tue, 19 Apr 2005 22:18:23 +0200, Antone Roundy wrote: > Replace the requirement for an xhtml:div wrapper for > content[type="xhmtl"] with an optional attribute to indicate whether the > top level element of XML content is a disposable wrapper or part of the > content. I really see no point in this. Well, I do, but it's not worth the hazzle of yet another attribute. Thus: -1. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Thu Apr 21 00:56:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00755 for ; Thu, 21 Apr 2005 00:56:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3L4ld5Y057714; Wed, 20 Apr 2005 21:47:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3L4ld1o057713; Wed, 20 Apr 2005 21:47:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtpauth05.mail.atl.earthlink.net (smtpauth05.mail.atl.earthlink.net [209.86.89.65]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3L4lagr057691 for ; Wed, 20 Apr 2005 21:47:38 -0700 (PDT) (envelope-from kevin@epeus.com) Received: from [68.164.89.32] (helo=[10.0.1.3]) by smtpauth05.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DOTbE-0002TK-0r; Thu, 21 Apr 2005 00:47:36 -0400 In-Reply-To: <42660DE4.7040906@atrus.org> References: <200504200656.CZK58727@ms8.netsolmail.com> <42660DE4.7040906@atrus.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <529bd17afa0ff865f68498890a0c4179@epeus.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: Kevin Marks Subject: licenses [was Re: NoIndex, again Date: Wed, 20 Apr 2005 21:47:28 -0700 To: "Nikolas 'Atrus' Coukouma" X-Mailer: Apple Mail (2.622) X-ELNK-Trace: b7e272d7a574036deb604bd72476f039239a348a220c2609d0a5172fa51dc4fdd6cf75cb8372cd25350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.89.32 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 20, 2005, at 1:08 AM, Nikolas 'Atrus' Coukouma wrote: >> > I didn't really want to discuss the licensing mess here. The previous > discussion seemed to conclude that it was risky and out of scope. I > just > wanted to note that some attempt had been made to make a > machine-readable description of licensing. Note that a simpler form of expressing this is rel="license", as defined here: http://developers.technorati.com/wiki/RelLicense and adopted by Creative Commons: http://lists.ibiblio.org/pipermail/cc-metadata/2004-February/000290.html and generated by their license server along with the RDF form http://creativecommons.org/license/ This seems a suitable atom-like way to express this (subject to Bob's caveats about ti being a positive grant rather than a restriction). From owner-atom-syntax@mail.imc.org Thu Apr 21 04:17:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04068 for ; Thu, 21 Apr 2005 04:17:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3L7vPCK067809; Thu, 21 Apr 2005 00:57:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3L7vPYN067808; Thu, 21 Apr 2005 00:57:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3L7vOoT067752 for ; Thu, 21 Apr 2005 00:57:24 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050421075718.DCDG2375.mta13-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com>; Thu, 21 Apr 2005 08:57:18 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20050421075718.PFYF1280.aamta05-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com>; Thu, 21 Apr 2005 08:57:18 +0100 Date: Thu, 21 Apr 2005 08:57:14 +0100 From: David Powell X-Mailer: The Bat! (v3.0.9.17 Return) Professional X-Priority: 3 (Normal) Message-ID: <78299899.20050421085714@djpowell.net> To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: xml:base and html rendering In-Reply-To: <4266E670.5000201@franklinmint.fm> References: <435944839.20050420235132@djpowell.net> <4266E670.5000201@franklinmint.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thursday, April 21, 2005, 12:32:00 AM, Robert Sayre wrote: > David Powell wrote: >> >> I recently tried to render a bunch of Atom entries as an HTML page and >> I hit a problem. I think it is probably worth mentioning now in case >> any implementors hadn't noticed it: >> >> Atom supports xml:base anywhere in the document, so different entries >> can have different base-URIs. HTML, however, doesn't support xml:base. >> This makes it difficult to display multiple entries on a HTML page. > I think we need to update the draft and stress that (X)HTML content is > not subject to xml:base processing. Only XHTML2 cites xml:base as a > normative reference and the xml:base spec is crystal-clear on the matter: I agree that xml:base isn't allowed inside XHTML content, but when used in an Atom feed, it still sets the base URI of the content eg:
Transforming entries with multiple base URI's into an HTML page is difficult. As Phil Ringnalda pointed out, HTML's tag can only be used once at the head of the page. Even without xml:base, it is still difficult to present a merged view of several feeds on a single HTML page. I expect that it is not just web-based aggregators like Bloglines that use this technique for rendering. RSS says nothing about relative references, and in Bloglines, at least, they don't seem to work. I'm wondering whether it would be better to require absolute URIs. >> Having implemented an Atom parser in XSLT as part of my Atom/RDF >> experiments, I tend to think that xml:base is more trouble than it is >> worth, and could be a barrier to interoperability given the common use >> case of using HTML to present entries. > I added xml:base support to Thunderbird's parser, but Mozilla's DOM > implementation happens to support the feature already, so it was a > one-liner. However, it is a DOM Level-3 feature, and I don't know how > prevalent support for it is. It might also interact poorly with other > parsing approachs. Feedback? It isn't too hard to add to SAX processors (just have a stack, resolve the base URI against the existing one at the top of the stack and push it onto the stack). DOM type processors should be reasonably too (find the route back to the root, reverse it, resolve any xml:base declarations on those elements). I have written an xml:base processor in XSLT, but it was very difficult due to XSLT's lack of a resolve-uri() function and its limited string handling. -- Dave From owner-atom-syntax@mail.imc.org Thu Apr 21 05:12:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08824 for ; Thu, 21 Apr 2005 05:12:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3L90Gc1002692; Thu, 21 Apr 2005 02:00:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3L90GYs002691; Thu, 21 Apr 2005 02:00:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3L90DoG002604 for ; Thu, 21 Apr 2005 02:00:14 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 72281 messnum 5267015 invoked from network[213.94.211.166/mail.724.ie]); 21 Apr 2005 09:00:06 -0000 Received: from mail.724.ie (HELO ?127.0.0.1?) (213.94.211.166) by mail04.svc.cra.dublin.eircom.net (qp 72281) with SMTP; 21 Apr 2005 09:00:06 -0000 Message-ID: <42676B93.3080402@dehora.net> Date: Thu, 21 Apr 2005 10:00:03 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: David Powell , atom-syntax@imc.org Subject: Re: xml:base and html rendering References: <435944839.20050420235132@djpowell.net> <4266E670.5000201@franklinmint.fm> In-Reply-To: <4266E670.5000201@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > David Powell wrote: > >> >> I recently tried to render a bunch of Atom entries as an HTML page and >> I hit a problem. I think it is probably worth mentioning now in case >> any implementors hadn't noticed it: >> >> Atom supports xml:base anywhere in the document, so different entries >> can have different base-URIs. HTML, however, doesn't support xml:base. >> This makes it difficult to display multiple entries on a HTML page. > > > I think we need to update the draft and stress that (X)HTML content is > not subject to xml:base processing. Why would we would mandate short-circuiting xml:base processing for XHTML via spec text, but default namespace processing via markup signals? Consistency would suggest some kind of wrapper/marker for xml:base. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 21 07:12:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15496 for ; Thu, 21 Apr 2005 07:12:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LAdGo5054123; Thu, 21 Apr 2005 03:39:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LAdGvu054121; Thu, 21 Apr 2005 03:39:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from earth.34sp.com (earth.34sp.com [195.50.105.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LAdESv054104 for ; Thu, 21 Apr 2005 03:39:15 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: (qmail 88469 invoked from network); 21 Apr 2005 10:39:13 -0000 Received: from localhost.34sp.com (HELO localhost) (127.0.0.1) by localhost.34sp.com with SMTP; 21 Apr 2005 10:39:13 -0000 Received: from 194.203.191.188 ([194.203.191.188]) by webmail.djpowell.net (IMP) with HTTP for ; Thu, 21 Apr 2005 11:39:13 +0100 Message-ID: <1114079953.426782d12c7a5@webmail.djpowell.net> Date: Thu, 21 Apr 2005 11:39:13 +0100 From: David Powell To: Bill de =?iso-8859-1?b?aNNyYQ==?= Cc: Robert Sayre , atom-syntax@imc.org Subject: Re: xml:base and html rendering MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 194.203.191.188 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Quoting Bill de hÓra : > > I think we need to update the draft and stress that (X)HTML content is > > not subject to xml:base processing. I didn't read this carefully enough when I replied earlier, I didn't see that Robert was suggesting that xml:base shouldn't apply to (X)HTML at all (which is what I was suggesting too). Don't forget that the URI of the Atom document also sets the base URI; xml:base is just one way that the base URI is set. A step further would be to say that content has no defined base URI, so relative references must not be used. > Why would we would mandate short-circuiting xml:base processing for > XHTML via spec text, but default namespace processing via markup > signals? Consistency would suggest some kind of wrapper/marker for xml:base. I don't really understand what you mean by a wrapper/marker, can you give an example? -- Dave From owner-atom-syntax@mail.imc.org Thu Apr 21 07:19:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15880 for ; Thu, 21 Apr 2005 07:19:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LB7fDf072463; Thu, 21 Apr 2005 04:07:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LB7f5v072460; Thu, 21 Apr 2005 04:07:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LB7dRL072417 for ; Thu, 21 Apr 2005 04:07:40 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 21 Apr 2005 21:07:31 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 21 Apr 2005 21:07:34 +1000 Subject: Re: xml:base and html rendering From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1114079953.426782d12c7a5@webmail.djpowell.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 21/4/05 8:39 PM, "David Powell" wrote: >> Why would we would mandate short-circuiting xml:base processing for >> XHTML via spec text, but default namespace processing via markup >> signals? Consistency would suggest some kind of wrapper/marker for xml:base. > > I don't really understand what you mean by a wrapper/marker, can you give an > example? like this?
...
 e. From owner-atom-syntax@mail.imc.org Thu Apr 21 07:49:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17941 for ; Thu, 21 Apr 2005 07:49:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LBc7K9089535; Thu, 21 Apr 2005 04:38:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LBc7oc089533; Thu, 21 Apr 2005 04:38:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3LBc6sT089456 for ; Thu, 21 Apr 2005 04:38:07 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 37121 messnum 3317804 invoked from network[213.94.211.166/mail.724.ie]); 21 Apr 2005 11:38:01 -0000 Received: from mail.724.ie (HELO ?127.0.0.1?) (213.94.211.166) by mail05.svc.cra.dublin.eircom.net (qp 37121) with SMTP; 21 Apr 2005 11:38:01 -0000 Message-ID: <42679095.4060702@dehora.net> Date: Thu, 21 Apr 2005 12:37:57 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Powell CC: Robert Sayre , atom-syntax@imc.org Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> In-Reply-To: <1114079953.426782d12c7a5@webmail.djpowell.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit David Powell wrote: > Quoting Bill de hÓra : > >>Why would we would mandate short-circuiting xml:base processing for >>XHTML via spec text, but default namespace processing via markup >>signals? Consistency would suggest some kind of wrapper/marker for xml:base. > > > I don't really understand what you mean by a wrapper/marker, can you give an > example? atom:content[@rel="freebase|nobase"] ? Just kidding... No, the thing is these two are similar problems structurally insofar as processing directives from the Atom layer are bleeding into the content. The way we're currently solving the namespace problem is via a xhtml:div tag in the format, plus spec text. The way Rob's suggesting we solve the xml:base directive is not via the format, just spec text. Also from one perspective, the latter case prefers a profiling of xml:base's scope whereas the former prefers to format defensively against namespace scope. Foolish inconsistencies notwithstanding, I would prefer we had a consistent approach here, since I'm not sure we've seen the last possible scoping issue. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 21 08:36:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21289 for ; Thu, 21 Apr 2005 08:36:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LCQcdh018780; Thu, 21 Apr 2005 05:26:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LCQcOS018779; Thu, 21 Apr 2005 05:26:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LCQalP018761 for ; Thu, 21 Apr 2005 05:26:36 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cceg25.cable.mindspring.com ([24.199.64.69] helo=[192.168.1.102]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DOalM-0000qb-Pc; Thu, 21 Apr 2005 12:26:32 +0000 Message-ID: <42679BF8.5080100@franklinmint.fm> Date: Thu, 21 Apr 2005 08:26:32 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: David Powell , atom-syntax@imc.org Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> In-Reply-To: <42679095.4060702@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > No, the thing is these two are similar problems structurally insofar as > processing directives from the Atom layer are bleeding into the content. No. xml:base doesn't mean anything in (x)html, ever, so there is no need for a structural measure. Additional spec text wouldn't be adding requirements, just spelling out what's implied by our references. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 21 08:47:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21878 for ; Thu, 21 Apr 2005 08:47:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LCdKAt025857; Thu, 21 Apr 2005 05:39:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LCdKZE025856; Thu, 21 Apr 2005 05:39:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LCdIdj025802 for ; Thu, 21 Apr 2005 05:39:19 -0700 (PDT) (envelope-from fora@annevankesteren.nl) Received: (qmail 20501 invoked by uid 10); 21 Apr 2005 12:33:26 -0000 Received: (vexira-qq 20494-9D425E66 invoked from network) 21 Apr 2005 14:33:25 +0200 Received: from unknown (HELO [127.0.0.1]) ([82.173.12.209]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 21 Apr 2005 12:33:25 -0000 Message-ID: <42679D9E.6010002@annevankesteren.nl> Date: Thu, 21 Apr 2005 14:33:34 +0200 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= , David Powell , atom-syntax@imc.org Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> In-Reply-To: <42679BF8.5080100@franklinmint.fm> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.30.0.2; VDF: 6.30.0.11; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: >> No, the thing is these two are similar problems structurally insofar >> as processing directives from the Atom layer are bleeding into the >> content. > > No. xml:base doesn't mean anything in (x)html, ever, so there is no need > for a structural measure. Additional spec text wouldn't be adding > requirements, just spelling out what's implied by our references. XHTML2 has xml:base and Mozilla for example supports xml:base in XHTML documents. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Thu Apr 21 09:36:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29537 for ; Thu, 21 Apr 2005 09:36:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LDOZOq043265; Thu, 21 Apr 2005 06:24:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LDOZXi043264; Thu, 21 Apr 2005 06:24:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LDOYt7043257 for ; Thu, 21 Apr 2005 06:24:35 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cceg25.cable.mindspring.com ([24.199.64.69] helo=[192.168.1.102]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DObfT-0001aP-Rz for atom-syntax@imc.org; Thu, 21 Apr 2005 13:24:31 +0000 Message-ID: <4267A990.3050606@franklinmint.fm> Date: Thu, 21 Apr 2005 09:24:32 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: xml:baseful test feed Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit What would be necessary to get this feed to render on one HTML page, ala Bloglines? http://www.franklinmint.fm/2005/04/21/xmlbase.atom Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 21 09:47:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00700 for ; Thu, 21 Apr 2005 09:47:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LDcSNF045466; Thu, 21 Apr 2005 06:38:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LDcSV4045465; Thu, 21 Apr 2005 06:38:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3LDcR0C045438 for ; Thu, 21 Apr 2005 06:38:28 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 66685 messnum 273899 invoked from network[213.94.211.166/mail.724.ie]); 21 Apr 2005 13:38:21 -0000 Received: from mail.724.ie (HELO ?127.0.0.1?) (213.94.211.166) by mail03.svc.cra.dublin.eircom.net (qp 66685) with SMTP; 21 Apr 2005 13:38:21 -0000 Message-ID: <4267ACC9.9030908@dehora.net> Date: Thu, 21 Apr 2005 14:38:17 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: David Powell , atom-syntax@imc.org Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> In-Reply-To: <42679BF8.5080100@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > Bill de hÓra wrote: > >> No, the thing is these two are similar problems structurally insofar >> as processing directives from the Atom layer are bleeding into the >> content. > > > No. xml:base doesn't mean anything in (x)html, ever, so there is no need > for a structural measure. Additional spec text wouldn't be adding > requirements, just spelling out what's implied by our references. Aside from what Anne said, I just scanned the XML Base spec and can't find anything scope wrt to child elements and attributes. In particular this (quoted previously here): [[[ The deployment of XML Base is through normative reference by new specifications, for example XLink and the XML Infoset. Applications and specifications built upon these new technologies will natively support XML Base. The behavior of xml:base attributes in applications based on specifications that do not have direct or indirect normative reference to XML Base is undefined. ]]] had nothing to say about scope. What is implied by our references appears to be it xml:base either evaluates to all the children under which it's declared or the behavior is undefined because the spec didn't define xml:base usage. So I guess my question is - how is scoping xml:base to not apply within atom:content where type is xhtml not profiling XML Base? cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 21 10:13:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03364 for ; Thu, 21 Apr 2005 10:13:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LDx8ib050303; Thu, 21 Apr 2005 06:59:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LDx8QL050302; Thu, 21 Apr 2005 06:59:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LDx5Ad050285 for ; Thu, 21 Apr 2005 06:59:06 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cceg25.cable.mindspring.com ([24.199.64.69] helo=[192.168.1.102]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DOcCr-0001xK-44; Thu, 21 Apr 2005 13:59:01 +0000 Message-ID: <4267B1A5.1010201@franklinmint.fm> Date: Thu, 21 Apr 2005 09:59:01 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: David Powell , atom-syntax@imc.org Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> In-Reply-To: <4267ACC9.9030908@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > What is implied by our references > appears to be it xml:base either evaluates to all the children under > which it's declared or the behavior is undefined because the spec didn't > define xml:base usage. > > So I guess my question is - how is scoping xml:base to not apply within > atom:content where type is xhtml not profiling XML Base? If were using XHTML2, I'd agree with you. The XHTML1 family doesn't use xml:base. A vocabularly must identify which of its elements are subject to xml:base processing. For example, "XLink normatively references XML Base for interpretation of relative URI references in xlink:href attribute". I suppose the case could be made that we're defining our own little language here, so we are within our rights. Not a very interesting question, because xml:base seems to create problems for aggregated HTML displays. A huge bug, IMHO. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 21 11:29:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09390 for ; Thu, 21 Apr 2005 11:29:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LFJEaR069662; Thu, 21 Apr 2005 08:19:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LFJE15069661; Thu, 21 Apr 2005 08:19:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LFJDRX069654 for ; Thu, 21 Apr 2005 08:19:13 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-2 ([129.148.9.73]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j3LFJCjG000211 for ; Thu, 21 Apr 2005 08:19:13 -0700 (PDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IFA00E01YISN6@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Thu, 21 Apr 2005 11:19:12 -0400 (EDT) Received: from localhost (vpn-129-150-35-43.Central.Sun.COM [129.150.35.43]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IFA00037YJZW9@bur-mail1.east.sun.com> for atom-syntax@imc.org; Thu, 21 Apr 2005 11:19:12 -0400 (EDT) Received: from ndw by localhost with local (Exim 4.50) id 1DOdSc-0000gB-RR for atom-syntax@imc.org; Thu, 21 Apr 2005 11:19:22 -0400 X-URL: http://nwalsh.com/ Date: Thu, 21 Apr 2005 11:19:05 -0400 From: Norman Walsh Subject: Re: xml:base and html rendering In-reply-to: <4267ACC9.9030908@dehora.net> To: atom-syntax@imc.org Message-id: <87k6mw88eu.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable / Bill de h=C3=93ra was heard to say: | Aside from what Anne said, I just scanned the XML Base spec and can't | find anything scope wrt to child elements and attributes. In | particular this (quoted previously here): | | [[[ | The deployment of XML Base is through normative reference by new | specifications, for example XLink and the XML Infoset. Applications | and specifications built upon these new technologies will natively | support XML Base. The behavior of xml:base attributes in applications | based on specifications that do not have direct or indirect normative | reference to XML Base is undefined. | ]]] | | had nothing to say about scope. What is implied by our references | appears to be it xml:base either evaluates to all the children under | which it's declared or the behavior is undefined because the spec | didn't define xml:base usage. | | So I guess my question is - how is scoping xml:base to not apply | within atom:content where type is xhtml not profiling XML Base? That would seem really strange to me. The xml:base attribute on an ancestor of atom:content changes the [base uri] property in the infoset. Down inside atom:content, suppose you find an html:div; what is its base URI? To answer that, you look for the applicable [base uri] property. I don't know any other way to do it. I suppose we could say that the base URI for atom:content is undefined but that seems odd too. It strikes me that that might be tricky too. Do we say that elements put in atom:content SHOULD use absolute URIs. We probably, uhm, should :-) Be seeing you, norm =2D-=20 Norman Walsh | It is good to have an end to journey http://nwalsh.com/ | toward; but it is the journey that | matters, in the end.--Ursula K. LeGuin --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCZ8RrOyltUcwYWjsRAhIyAJ0VpnTMbeTA9/Bm9ke3kX5mWmPZCQCglW7U z1IcZ1p1WNib/JT0vQ1jbp4= =wOck -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Apr 21 11:29:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09408 for ; Thu, 21 Apr 2005 11:29:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LFJ67o069620; Thu, 21 Apr 2005 08:19:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LFJ6aE069619; Thu, 21 Apr 2005 08:19:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LFJ3X3069572 for ; Thu, 21 Apr 2005 08:19:04 -0700 (PDT) (envelope-from philringnalda@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so953330wri for ; Thu, 21 Apr 2005 08:18:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=U8KJ4G0LhRpai7qPHsQd9mMl3wrvbVpbeAQm8f58Rt/lsQSDkYVhFQ1SAK7Bc1yRuKnRqVfEmNg9SlnjctP/hAw3x5ME4L6y3xW2kRnOQGHN7E5F7F29x9QMx9BzdWfcrobjGC0OOtTB2LXps5Y0wPIq2ZbHegOjdpgKKwQ/35c= Received: by 10.54.42.50 with SMTP id p50mr7822413wrp; Thu, 21 Apr 2005 08:13:06 -0700 (PDT) Received: from ?12.45.57.149? ([12.45.57.149]) by mx.gmail.com with ESMTP id 13sm640035wrl.2005.04.21.08.12.27; Thu, 21 Apr 2005 08:12:28 -0700 (PDT) Message-ID: <4267C2D6.1060702@gmail.com> Date: Thu, 21 Apr 2005 08:12:22 -0700 From: Phil Ringnalda User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom-Syntax Subject: Re: xml:baseful test feed References: <4267A990.3050606@franklinmint.fm> In-Reply-To: <4267A990.3050606@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > What would be necessary to get this feed to render on one HTML page, ala > Bloglines? > > http://www.franklinmint.fm/2005/04/21/xmlbase.atom > Running it through a competant Atom processor? http://feedparser.org/docs/resolving-relative-links.html Phil Ringnalda From owner-atom-syntax@mail.imc.org Thu Apr 21 12:00:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11668 for ; Thu, 21 Apr 2005 12:00:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LFnmwT077438; Thu, 21 Apr 2005 08:49:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LFnmM4077437; Thu, 21 Apr 2005 08:49:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LFnmbv077422 for ; Thu, 21 Apr 2005 08:49:48 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cceg25.cable.mindspring.com ([24.199.64.69] helo=[192.168.1.102]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DOdw0-0002zq-Rz; Thu, 21 Apr 2005 15:49:44 +0000 Message-ID: <4267CB99.2080701@franklinmint.fm> Date: Thu, 21 Apr 2005 11:49:45 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phil Ringnalda CC: Atom-Syntax Subject: Re: xml:baseful test feed References: <4267A990.3050606@franklinmint.fm> <4267C2D6.1060702@gmail.com> In-Reply-To: <4267C2D6.1060702@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Phil Ringnalda wrote: > Robert Sayre wrote: > >> >> What would be necessary to get this feed to render on one HTML page, >> ala Bloglines? >> >> http://www.franklinmint.fm/2005/04/21/xmlbase.atom >> > > Running it through a competant Atom processor? > > http://feedparser.org/docs/resolving-relative-links.html That's cool! It might be more honest to say "HTML is munged according to the in-scope xml:base." So, do we require content munging, or not? Bloglines fails this: http://feedparser.org/docs/examples/base.xml but NetNewsWire succeeds. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 21 12:00:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11691 for ; Thu, 21 Apr 2005 12:00:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LFjhqM076380; Thu, 21 Apr 2005 08:45:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LFjh8e076379; Thu, 21 Apr 2005 08:45:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3LFjgAl076360 for ; Thu, 21 Apr 2005 08:45:43 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 45142 messnum 5265200 invoked from network[213.94.211.166/mail.724.ie]); 21 Apr 2005 15:45:37 -0000 Received: from mail.724.ie (HELO ?127.0.0.1?) (213.94.211.166) by mail04.svc.cra.dublin.eircom.net (qp 45142) with SMTP; 21 Apr 2005 15:45:37 -0000 Message-ID: <4267CA9C.9020008@dehora.net> Date: Thu, 21 Apr 2005 16:45:32 +0100 From: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Walsh CC: atom-syntax@imc.org Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> In-Reply-To: <87k6mw88eu.fsf@nwalsh.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > | So I guess my question is - how is scoping xml:base to not apply > | within atom:content where type is xhtml not profiling XML Base? > > That would seem really strange to me. The xml:base attribute on an > ancestor of atom:content changes the [base uri] property in the > infoset. Down inside atom:content, suppose you find an html:div; what > is its base URI? To answer that, you look for the applicable [base > uri] property. I don't know any other way to do it. Sure. My point (which still stands afaict) is that this is a structural matter, to do with bleed from the container in the content and that we've solved it with a different approach altogether for namespaces than what's being suggested for xml:base. I guess I'm trying to get the WG to think about at this an 'document architecture' level rather than patching issues on a per case basis as we find them. But I guess people can judge for themselves whether the fact that Atom might corrupt carried content is an issue. > Do we say that elements put in atom:content SHOULD use absolute URIs. > We probably, uhm, should :-) I agree, but you don't sound sure :-) cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 21 12:00:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11723 for ; Thu, 21 Apr 2005 12:00:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LFr46G078202; Thu, 21 Apr 2005 08:53:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LFr4an078201; Thu, 21 Apr 2005 08:53:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LFr40o078195 for ; Thu, 21 Apr 2005 08:53:04 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cceg25.cable.mindspring.com ([24.199.64.69] helo=[192.168.1.102]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DOdz4-00032F-Ja; Thu, 21 Apr 2005 15:52:54 +0000 Message-ID: <4267CC57.3050100@franklinmint.fm> Date: Thu, 21 Apr 2005 11:52:55 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= CC: Norman Walsh , atom-syntax@imc.org Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> <4267CA9C.9020008@dehora.net> In-Reply-To: <4267CA9C.9020008@dehora.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > I guess I'm trying to get the WG to > think about at this an 'document architecture' level rather than > patching issues on a per case basis as we find them. But I guess people > can judge for themselves whether the fact that Atom might corrupt > carried content is an issue. What should we do about the 'document architecture'? Suggestions? Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 21 12:00:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11747 for ; Thu, 21 Apr 2005 12:00:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LFnU3g077346; Thu, 21 Apr 2005 08:49:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LFnUo8077345; Thu, 21 Apr 2005 08:49:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LFnT2O077338 for ; Thu, 21 Apr 2005 08:49:29 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:49771 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228689AbVDUPt2 (ORCPT ); Thu, 21 Apr 2005 18:49:28 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <42679BF8.5080100@franklinmint.fm> References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <89a7f2382880cdfef6c3606bb4f767bf@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: xml:base and html rendering Date: Thu, 21 Apr 2005 18:49:13 +0300 To: Atom Syntax X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 21, 2005, at 15:26, Robert Sayre wrote: > No. xml:base doesn't mean anything in (x)html, ever, so there is no > need for a structural measure. In practice, anything that end up in the xml: namespace is part of the infrastructure and generic underpinnings won't turn them off based on higher-level specs. Are you suggesting Mozilla is wrong in supporting xml:base in a generic way (including in XHTML)? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Thu Apr 21 12:45:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16091 for ; Thu, 21 Apr 2005 12:45:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LGVoYm090866; Thu, 21 Apr 2005 09:31:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LGVo6G090865; Thu, 21 Apr 2005 09:31:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LGVoXh090857 for ; Thu, 21 Apr 2005 09:31:50 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DOeag-0003SR-Iu; Thu, 21 Apr 2005 16:31:46 +0000 Message-ID: <4267D571.80708@franklinmint.fm> Date: Thu, 21 Apr 2005 12:31:45 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henri Sivonen CC: Atom Syntax Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <89a7f2382880cdfef6c3606bb4f767bf@iki.fi> In-Reply-To: <89a7f2382880cdfef6c3606bb4f767bf@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henri Sivonen wrote: > > Are you suggesting Mozilla is wrong in supporting xml:base in a generic > way (including in XHTML)? I don't care about Mozilla (right now). We have xml:base, and we know it's not going to work quite right, all of the time. Either we warn people, or we don't. This may signal a deeper problem with xml:base, or XML itself. If Atom Processors are to take the Feedparser approach, they shouldn't be used as endpoints for the protocol, because you don't want the server changing your nice, short relative references into full URIs. I'm not sure any spec language will help. Maybe 'use absolute URIs for maximum data integrity', but I suppose that is always true. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 21 13:04:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17373 for ; Thu, 21 Apr 2005 13:04:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LGtVR1098135; Thu, 21 Apr 2005 09:55:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LGtVXU098134; Thu, 21 Apr 2005 09:55:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3LGtU0P098072 for ; Thu, 21 Apr 2005 09:55:30 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 77031 messnum 2895366 invoked from network[213.94.211.166/mail.724.ie]); 21 Apr 2005 16:55:24 -0000 Received: from mail.724.ie (HELO ?127.0.0.1?) (213.94.211.166) by mail07.svc.cra.dublin.eircom.net (qp 77031) with SMTP; 21 Apr 2005 16:55:24 -0000 Message-ID: <4267DAF7.1010400@dehora.net> Date: Thu, 21 Apr 2005 17:55:19 +0100 From: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> <4267CA9C.9020008@dehora.net> <4267CC57.3050100@franklinmint.fm> In-Reply-To: <4267CC57.3050100@franklinmint.fm> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > Bill de hÓra wrote: > >> I guess I'm trying to get the WG to think about at this an 'document >> architecture' level rather than patching issues on a per case basis as >> we find them. But I guess people can judge for themselves whether the >> fact that Atom might corrupt carried content is an issue. > > > What should we do about the 'document architecture'? Suggestions? I'm not sure anyone here agrees there's a 'document architecture' issue to begin with :\ That said, consistency of approach would be good, or at least articulating why consistency isn't needed in these cases would be good. Being explicit about profiling would be good if that's what we're going to do. Being sure that adding features like xml:base and xhtml:div are not more trouble than they're worth is good. Test cases would be good (thank you for yours). Here's what we don't do - fob it off to the Fabled Implementors Guide, or find out a week after we ship we made more Terrible Mistakes than we needed to. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 21 13:35:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20299 for ; Thu, 21 Apr 2005 13:35:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LHOxtA006860; Thu, 21 Apr 2005 10:24:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LHOxOa006859; Thu, 21 Apr 2005 10:24:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3LHOv7p006830 for ; Thu, 21 Apr 2005 10:24:58 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 21 Apr 2005 17:24:51 -0000 Received: from xdsl-81-173-172-86.netcologne.de (EHLO klangraum) [81.173.172.86] by mail.gmx.net (mp019) with SMTP; 21 Apr 2005 19:24:51 +0200 X-Authenticated: #163624 Date: Thu, 21 Apr 2005 19:27:48 +0200 From: "A. Pagaltzis" To: atom-syntax@imc.org Subject: Re: xml:base and html rendering Message-ID: <20050421172748.GA14632@klangraum> Mail-Followup-To: atom-syntax@imc.org References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> <4267CA9C.9020008@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4267CA9C.9020008@dehora.net> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Bill de hÓra [2005-04-21 17:55]: > My point (which still stands afaict) is that this is a > structural matter, to do with bleed from the container in the > content and that we've solved it with a different approach > altogether for namespaces than what's being suggested for > xml:base. I guess I'm trying to get the WG to think about at > this an 'document architecture' level rather than patching > issues on a per case basis as we find them. On the structural level these all sound like issues of XML-in-XML in general, not Atom in specific. I don’t mean in the sense of how to do that with XML at all; I mean in the sense of how XML vocabularies should be designed so they can be integrated cleanly. It looks like this is largely unexplored area without any best practices to speak of so far. This is merely an observation. I’m not sure what it means for Atom. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Thu Apr 21 14:15:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23676 for ; Thu, 21 Apr 2005 14:15:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LI63dP015843; Thu, 21 Apr 2005 11:06:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LI63OR015842; Thu, 21 Apr 2005 11:06:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LI60t1015825 for ; Thu, 21 Apr 2005 11:06:01 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DOg3o-0004jN-Mv; Thu, 21 Apr 2005 18:05:56 +0000 Message-ID: <4267EB83.1070103@franklinmint.fm> Date: Thu, 21 Apr 2005 14:05:55 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?QmlsbCBkZSBow5NyYQ==?= CC: atom-syntax@imc.org, David Powell Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> <4267CA9C.9020008@dehora.net> <4267CC57.3050100@franklinmint.fm> <4267DAF7.1010400@dehora.net> In-Reply-To: <4267DAF7.1010400@dehora.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > Being explicit about profiling would be good if that's what > we're going to do. Being sure that adding features like xml:base and > xhtml:div are not more trouble than they're worth is good. On xml:base, I don't think we actually have a problem with the document architecture. If you're processing an Atom entry you get an (X)HTML fragment and a base URI. The information is there, it's just that it may be difficult to *leave* the Atom format and repurpose it. So, is there something more useful we could provide? Looks like the generic relative/absolute trade-off. If you've got an embedded HTML library, you can probably deal with it just fine. If you have a web interface, you get the nasty problem of combining the content into one HTML format and base URI. It might be possible to deal with baseURIs using event bubbling or other JS hacks, but that won't help spiders and such. The Feedparser approach is fine, but it's definitely not the definition of a 'competant' Atom Processor, energetic as it is. Roundtripping might be more important that HTML munging. David has previously mentioned xml:base interactions with atom:source. Any other issues? I guess we could also use a quick survey of xml:base support in parsers, xslt implementations, etc. if we don't already have one. xml:base was supposed to be in XSLT 1.1, and Saxon supports it right now. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 21 16:15:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11306 for ; Thu, 21 Apr 2005 16:15:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LK4jNV049617; Thu, 21 Apr 2005 13:04:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3LK4jEC049616; Thu, 21 Apr 2005 13:04:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3LK4iB2049610 for ; Thu, 21 Apr 2005 13:04:44 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from phys-bur-2 ([129.148.9.73]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3LK4hjO004949 for ; Thu, 21 Apr 2005 14:04:43 -0600 (MDT) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IFB00B01BLM2T@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Thu, 21 Apr 2005 16:04:43 -0400 (EDT) Received: from localhost (vpn-129-150-35-43.Central.Sun.COM [129.150.35.43]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IFB0093IBRU1E@bur-mail1.east.sun.com> for atom-syntax@imc.org; Thu, 21 Apr 2005 16:04:43 -0400 (EDT) Received: from ndw by localhost with local (Exim 4.50) id 1DOhuv-0005I0-0b for atom-syntax@imc.org; Thu, 21 Apr 2005 16:04:53 -0400 X-URL: http://nwalsh.com/ Date: Thu, 21 Apr 2005 16:04:47 -0400 From: Norman Walsh Subject: Re: xml:base and html rendering In-reply-to: <4267EB83.1070103@franklinmint.fm> To: atom-syntax@imc.org Message-id: <87u0lz28ww.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> <4267CA9C.9020008@dehora.net> <4267CC57.3050100@franklinmint.fm> <4267DAF7.1010400@dehora.net> <4267EB83.1070103@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Robert Sayre was heard to say: | I guess we could also use a quick survey of xml:base support in | parsers, xslt implementations, etc. if we don't already have one. | xml:base was supposed to be in XSLT 1.1, and Saxon supports it right | now. Support for xml:base is part of the XPath 2 family of specs. Be seeing you, norm =2D-=20 Norman Walsh | Men are more like the times they live http://nwalsh.com/ | in than they are like their | fathers.--Ali Ibn-abi-talib --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD4DBQBCaAdfOyltUcwYWjsRAk14AJiNTajzCNHpK1eRRbARhda1XAdVAJwNXVMm z4lVCNF6ib4PDsdq6Qvxag== =1Urx -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Fri Apr 22 03:18:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19402 for ; Fri, 22 Apr 2005 03:18:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M773Sb073313; Fri, 22 Apr 2005 00:07:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3M773sa073312; Fri, 22 Apr 2005 00:07:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M771CH073233 for ; Fri, 22 Apr 2005 00:07:02 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from cegetel.net (217-19-192-100.dti.cegetel.net [217.19.192.100]) by smtp.cegetel.net (Postfix) with SMTP id 0EC653181E7 for ; Fri, 22 Apr 2005 09:06:53 +0200 (CEST) Received: from 82.127.77.43 (SquirrelMail authenticated user t.broyer@cegetel.net) by ssl-webmail.sitadelle.com with HTTP; Fri, 22 Apr 2005 09:06:56 +0200 (CEST) Message-ID: <1927.82.127.77.43.1114153616.squirrel@ssl-webmail.sitadelle.com> Date: Fri, 22 Apr 2005 09:06:56 +0200 (CEST) Subject: Base URI and link rel="self" From: "Thomas Broyer" To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit As some of you have already said, the problem isn't really xml:base but the base URI. Here's one more question: when a feed have no xml:base, it's base URI is the URI from where is has been retrieved. But when I make a local copy of a feed, I change its URI, however URIs in the feed should (from the user point of view) still be resolved relative to the original feed URI. So should copies of a feed be modified to add an xml:base to the document element? I don't think so... The other solution is to have link rel="self" redefine the document base URI when no base URI was explicitly set before (using an xml:base attribute on an ancestor element). But Atom being using interlaced content models, an atom:image or atom:icon (as well as other link elements) might appear before the link rel="self" and use relative URIs: should they be resolved relative to the link rel="self"? which means parsing all the feed metadata before resolving relative URIs to absolute ones... So, link rel="self" not being a quite good solution, should Atom mandate (or otherwise strongly recommend) using an xml:base attribute as soon as the feed uses relative URIs? As said above, the base URI problem is not only an xml:base one... and it's not easy to solve... -- Thomas Broyer From owner-atom-syntax@mail.imc.org Fri Apr 22 03:52:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22609 for ; Fri, 22 Apr 2005 03:52:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M7X2tp090591; Fri, 22 Apr 2005 00:33:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3M7X2Ti090589; Fri, 22 Apr 2005 00:33:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M7X2Yr090491 for ; Fri, 22 Apr 2005 00:33:02 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFC00CQD7CG7WC0@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Fri, 22 Apr 2005 09:26:40 +0200 (CEST) Received: from quark ([80.203.88.140]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFC0071R7NRLNA0@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Fri, 22 Apr 2005 09:33:27 +0200 (CEST) Date: Fri, 22 Apr 2005 09:35:29 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Base URI and link rel="self" In-reply-to: <1927.82.127.77.43.1114153616.squirrel@ssl-webmail.sitadelle.com> To: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <1927.82.127.77.43.1114153616.squirrel@ssl-webmail.sitadelle.com> User-Agent: Opera M2/8.0 (Win32, build 7561) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Fri, 22 Apr 2005 09:06:56 +0200, Thomas Broyer wrote: > As said above, the base URI problem is not only an xml:base one... and > it's not easy to solve... Well, actually it is. It's a huge camel to digest, but the solution is to require absolute URI's in all resource references in Atom. Perhaps we could combine this with requiring use of xml:base, but it should at least never be necessary to find the Atom document's base URI from the document's original location, because that location might change rapidly. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Apr 22 04:07:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23626 for ; Fri, 22 Apr 2005 04:07:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M7wV2E001174; Fri, 22 Apr 2005 00:58:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3M7wVdY001173; Fri, 22 Apr 2005 00:58:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M7wUc6001084 for ; Fri, 22 Apr 2005 00:58:31 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta04-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050422075823.SDG21834.mta09-winn.mailhost.ntl.com@aamta04-winn.mailhost.ntl.com>; Fri, 22 Apr 2005 08:58:23 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta04-winn.mailhost.ntl.com with ESMTP id <20050422075823.QBMK1352.aamta04-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com>; Fri, 22 Apr 2005 08:58:23 +0100 Date: Fri, 22 Apr 2005 08:58:20 +0100 From: David Powell X-Mailer: The Bat! (v3.0.9.17 Return) Professional X-Priority: 3 (Normal) Message-ID: <43988300.20050422085820@djpowell.net> To: "Thomas Broyer" CC: atom-syntax@imc.org Subject: Re: Base URI and link rel="self" In-Reply-To: <1927.82.127.77.43.1114153616.squirrel@ssl-webmail.sitadelle.com> References: <1927.82.127.77.43.1114153616.squirrel@ssl-webmail.sitadelle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Friday, April 22, 2005, 8:06:56 AM, Thomas Broyer wrote: > As some of you have already said, the problem isn't really xml:base but > the base URI. > Here's one more question: when a feed have no xml:base, it's base URI is > the URI from where is has been retrieved. Don't forget that the Content-Location header overrides the document URI if it is present. > But when I make a local copy of a feed, I change its URI, Transferring Atom using protocols that don't use retrieval URIs will have similar problems, eg: XMPP, Email, and whatever mobile push technologies might be used in the future. > however URIs in the feed should (from the user point of view) still > be resolved relative to the original feed URI. So should copies of a > feed be modified to add an xml:base to the document element? I don't > think so... > The other solution is to have link rel="self" redefine > the document base URI when no base URI was explicitly set before > (using an xml:base attribute on an ancestor element). But Atom being > using interlaced content models, an atom:image or atom:icon (as well > as other link elements) might appear before the link rel="self" and > use relative URIs: should they be resolved relative to the link > rel="self"? which means parsing all the feed metadata before > resolving relative URIs to absolute ones... So, link rel="self" not > being a quite good solution, should Atom mandate (or otherwise > strongly recommend) using an xml:base attribute as soon as the feed > uses relative URIs? It still doesn't solve all of the problems though: Even if you know the base-URI of an entry, it can still be different to other entries, from the same feed, and from other feeds, so to display these together on an HTML page you would need to rewrite the HTML document with resolved links. -- Dave From owner-atom-syntax@mail.imc.org Fri Apr 22 04:07:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23644 for ; Fri, 22 Apr 2005 04:07:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M7xxs7001975; Fri, 22 Apr 2005 00:59:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3M7xxxn001974; Fri, 22 Apr 2005 00:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta09-winn.mailhost.ntl.com (smtpout17.mailhost.ntl.com [212.250.162.17]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M7xwK1001930 for ; Fri, 22 Apr 2005 00:59:58 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta09-winn.mailhost.ntl.com with ESMTP id <20050422075952.XZG21834.mta09-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com>; Fri, 22 Apr 2005 08:59:52 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050422075952.ZZUF1844.aamta08-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com>; Fri, 22 Apr 2005 08:59:52 +0100 Date: Fri, 22 Apr 2005 08:59:50 +0100 From: David Powell X-Mailer: The Bat! (v3.0.9.17 Return) Professional X-Priority: 3 (Normal) Message-ID: <1529044106.20050422085950@djpowell.net> To: Robert Sayre CC: =?ISO-8859-15?Q?Bill_de_h=D3ra?= , atom-syntax@imc.org Subject: Re: xml:base and html rendering In-Reply-To: <4267EB83.1070103@franklinmint.fm> References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> <4267CA9C.9020008@dehora.net> <4267CC57.3050100@franklinmint.fm> <4267DAF7.1010400@dehora.net> <4267EB83.1070103@franklinmint.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3M7xwK1001967 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Thursday, April 21, 2005, 7:05:55 PM, you wrote: > I guess we could also use a quick survey of xml:base support in parsers, > xslt implementations, etc. if we don't already have one. > xml:base was supposed to be in XSLT 1.1, and Saxon supports it right > now. Does XSLT 1.1 support xml:base in the source document? My reading of it was that it just supported it in the stylesheet itself. -- Dave From owner-atom-syntax@mail.imc.org Fri Apr 22 04:16:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24180 for ; Fri, 22 Apr 2005 04:16:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M88QHF006690; Fri, 22 Apr 2005 01:08:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3M88Qkm006689; Fri, 22 Apr 2005 01:08:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M88PWV006627 for ; Fri, 22 Apr 2005 01:08:26 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta07-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050422080816.GZFU3252.mta08-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com>; Fri, 22 Apr 2005 09:08:16 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta07-winn.mailhost.ntl.com with ESMTP id <20050422080816.HSMZ10174.aamta07-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com>; Fri, 22 Apr 2005 09:08:16 +0100 Date: Fri, 22 Apr 2005 09:08:14 +0100 From: David Powell X-Mailer: The Bat! (v3.0.9.17 Return) Professional X-Priority: 3 (Normal) Message-ID: <259785617.20050422090814@djpowell.net> To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= CC: Atom-Syntax Subject: Re: Base URI and link rel="self" In-Reply-To: References: <1927.82.127.77.43.1114153616.squirrel@ssl-webmail.sitadelle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3M88QWV006683 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Friday, April 22, 2005, 8:35:29 AM, you wrote: > On Fri, 22 Apr 2005 09:06:56 +0200, Thomas Broyer > wrote: >> As said above, the base URI problem is not only an xml:base one... and >> it's not easy to solve... > Well, actually it is. It's a huge camel to digest, but the solution is to > require absolute URI's in all resource references in Atom. Perhaps we > could combine this with requiring use of xml:base, but it should at least > never be necessary to find the Atom document's base URI from the > document's original location, because that location might change rapidly. Well there are two problems: One problem is that HTML content with mixed base-URIs can't be presented as HTML. This only solution I can think of is to require atom:content not to use relative URIs. Another way of phrasing this (which might be a bit more future proof against future formats), is that content inside Text constructs/atom:content has no base-URI. Another problem is that the Atom documents are transferred to clients, and possibly sent over other protocols where the base-URI could be lost. This isn't such a big problem. The clients could tag the root element with xml:base (making sure to resolve any xml:base already there against the new one). Another option would be to store the base-URI externally as metadata in the transfer protocols, or in a databases for the case of local content. Of course if we saw both of these as problems then we could fix them both by taking out xml:base everywhere except for a required xml:base on the root. -- Dave From owner-atom-syntax@mail.imc.org Fri Apr 22 05:18:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27731 for ; Fri, 22 Apr 2005 05:18:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M97UsK036655; Fri, 22 Apr 2005 02:07:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3M97UXV036652; Fri, 22 Apr 2005 02:07:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M97S8S036579 for ; Fri, 22 Apr 2005 02:07:29 -0700 (PDT) (envelope-from asbjorn@tigerstaden.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFC00CPTBQSV9A0@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Fri, 22 Apr 2005 11:01:40 +0200 (CEST) Received: from quark ([80.203.88.140]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFC007CQC23N1H0@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Fri, 22 Apr 2005 11:08:27 +0200 (CEST) Date: Fri, 22 Apr 2005 11:10:29 +0200 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: Base URI and link rel="self" In-reply-to: <259785617.20050422090814@djpowell.net> To: David Powell Cc: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <1927.82.127.77.43.1114153616.squirrel@ssl-webmail.sitadelle.com> <259785617.20050422090814@djpowell.net> User-Agent: Opera M2/8.0 (Win32, build 7561) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Fri, 22 Apr 2005 10:08:14 +0200, David Powell wrote: > Of course if we saw both of these as problems then we could fix them > both by taking out xml:base everywhere except for a required xml:base > on the root. I think this is a good solution, but how do we mandate that 'xml:base' applies to non-XML content? Will it? Won't it? Will a required 'xml:base' on the root element apply to all XML content in Atom Text Contructs, but not to HTML? -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Fri Apr 22 05:38:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29199 for ; Fri, 22 Apr 2005 05:38:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M9VkkV053545; Fri, 22 Apr 2005 02:31:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3M9Vk28053542; Fri, 22 Apr 2005 02:31:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M9VjKo053492 for ; Fri, 22 Apr 2005 02:31:46 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 22 Apr 2005 19:31:37 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 22 Apr 2005 19:31:40 +1000 Subject: Re: Base URI and link rel="self" From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3M9VkKo053535 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 22/4/05 7:10 PM, "Asbjørn Ulsberg" wrote: > I think this is a good solution, but how do we mandate that 'xml:base' > applies to non-XML content? Will it? Won't it? Will a required 'xml:base' > on the root element apply to all XML content in Atom Text Contructs, but > not to HTML? what about this case: (where the resource 123.html contains relative URIs) e. From owner-atom-syntax@mail.imc.org Fri Apr 22 05:42:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29518 for ; Fri, 22 Apr 2005 05:42:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M9b2Ov057142; Fri, 22 Apr 2005 02:37:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3M9b2bq057141; Fri, 22 Apr 2005 02:37:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from earth.34sp.com (earth.34sp.com [195.50.105.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3M9b1oH057126 for ; Fri, 22 Apr 2005 02:37:01 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: (qmail 72087 invoked from network); 22 Apr 2005 09:37:00 -0000 Received: from localhost.34sp.com (HELO localhost) (127.0.0.1) by localhost.34sp.com with SMTP; 22 Apr 2005 09:37:00 -0000 Received: from 194.203.191.188 ([194.203.191.188]) by webmail.djpowell.net (IMP) with HTTP for ; Fri, 22 Apr 2005 10:37:00 +0100 Message-ID: <1114162620.4268c5bc1d246@webmail.djpowell.net> Date: Fri, 22 Apr 2005 10:37:00 +0100 From: David Powell To: =?iso-8859-1?b?QXNiavhybg==?= Ulsberg Cc: Atom-Syntax Subject: Re: Base URI and link rel="self" References: <1927.82.127.77.43.1114153616.squirrel@ssl-webmail.sitadelle.com> <259785617.20050422090814@djpowell.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 194.203.191.188 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Quoting Asbjørn Ulsberg : > > On Fri, 22 Apr 2005 10:08:14 +0200, David Powell > wrote: > > > Of course if we saw both of these as problems then we could fix them > > both by taking out xml:base everywhere except for a required xml:base > > on the root. > > I think this is a good solution, but how do we mandate that 'xml:base' > applies to non-XML content? Will it? Won't it? Will a required 'xml:base' > on the root element apply to all XML content in Atom Text Contructs, but > not to HTML? Sorry, my conclusion was wrong. Requiring xml:base at the root, wouldn't fix the problem of relative links being hard to resolve in HTML/XHTML. We would still need the HTML/XHTML content to only contain absolute links otherwise "newspaper views" of several feeds wouldn't be possible, because entries from different feeds could still have different bases. But, if we did say that HTML/XHTML can only contain absolute links, then we might decide that the benefit of allowing xml:base everywhere just for things like atom:link isn't worth it. -- Dave From owner-atom-syntax@mail.imc.org Fri Apr 22 09:43:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18486 for ; Fri, 22 Apr 2005 09:43:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MDUMjY074396; Fri, 22 Apr 2005 06:30:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MDUMax074395; Fri, 22 Apr 2005 06:30:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MDUKs4074381 for ; Fri, 22 Apr 2005 06:30:20 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cceg25.cable.mindspring.com ([24.199.64.69] helo=[192.168.1.102]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DOyEa-0001Ot-LZ; Fri, 22 Apr 2005 13:30:16 +0000 Message-ID: <4268FC68.5000604@franklinmint.fm> Date: Fri, 22 Apr 2005 09:30:16 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Powell CC: =?ISO-8859-15?Q?Bill_de_h=D3ra?= , atom-syntax@imc.org Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> <4267CA9C.9020008@dehora.net> <4267CC57.3050100@franklinmint.fm> <4267DAF7.1010400@dehora.net> <4267EB83.1070103@franklinmint.fm> <1529044106.20050422085950@djpowell.net> In-Reply-To: <1529044106.20050422085950@djpowell.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Powell wrote: > Does XSLT 1.1 support xml:base in the source document? My reading of > it was that it just supported it in the stylesheet itself. Perhaps you're right. Looking closer, Saxon seems to support XPath2 these days (Saxon 8.4B) including the function fn:resolve-uri. XSLT1.1 was cancelled anyway, I think. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Apr 22 10:58:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25551 for ; Fri, 22 Apr 2005 10:58:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MEgioi094314; Fri, 22 Apr 2005 07:42:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MEgiwH094313; Fri, 22 Apr 2005 07:42:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MEgh8o094293 for ; Fri, 22 Apr 2005 07:42:43 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3MEe1le017942; Fri, 22 Apr 2005 15:40:07 +0100 (BST) In-Reply-To: <4267EB83.1070103@franklinmint.fm> References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> <4267CA9C.9020008@dehora.net> <4267CC57.3050100@franklinmint.fm> <4267DAF7.1010400@dehora.net> <4267EB83.1070103@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <429ca72206330e34982f9758e3593819@mac.com> Cc: atom-syntax From: Graham Subject: Re: xml:base and html rendering Date: Fri, 22 Apr 2005 15:40:06 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3MEgi8o094307 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 21 Apr 2005, at 7:05 pm, Robert Sayre wrote: > Bill de hÓra wrote: > >> Being explicit about profiling would be good if that's what we're >> going to do. Being sure that adding features like xml:base and >> xhtml:div are not more trouble than they're worth is good. > > On xml:base, I don't think we actually have a problem with the > document architecture. If you're processing an Atom entry you get an > (X)HTML fragment and a base URI. The information is there, it's just > that it may be difficult to *leave* the Atom format and repurpose it. > So, is there something more useful we could provide? Looks like the > generic relative/absolute trade-off. Completely agree. Any content that allows relative links within itself would have to have some concept of an external base URI, whether or not the content format supports xml:base itself internally. An Atom processor just has to hand over the chunk of data and the current state of xml:base. I think the appropriate way to put multiple entries onto one HTML page would is for the app doing to rewrite the URIs inside it to be absolute. Requiring URIs in the content to be absolute to begin with is too expensive, and probably completely unenforceable. Graham From owner-atom-syntax@mail.imc.org Fri Apr 22 12:46:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03133 for ; Fri, 22 Apr 2005 12:46:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MGYPHM023863; Fri, 22 Apr 2005 09:34:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MGYPKe023862; Fri, 22 Apr 2005 09:34:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MGYOZW023848 for ; Fri, 22 Apr 2005 09:34:24 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3MGYOi7014134 for ; Fri, 22 Apr 2005 10:34:24 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IFC007KFWPBCA@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 22 Apr 2005 10:34:24 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFC002YNWPBUG@mail.sun.net> for atom-syntax@imc.org; Fri, 22 Apr 2005 10:34:23 -0600 (MDT) Date: Fri, 22 Apr 2005 12:19:06 -0400 From: John Cowan Subject: Comments on atompub-format-08 (Modified by Tim Bray) To: Tim.Bray@Sun.COM Message-id: <7bde7e725ebf119c04ffa34cf82d488d@reutershealth.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Redirected from John Cowan -Tim ==================================================================== I heard about the Last Call via Ongoing, so I'm going to pester you with these rather than doing the Right Thing, because at the moment I'm too swamped to find out what the Right Thing is. Feel free to squelch any of these that have been already discussed to death, or to point me to the Right Thing. 3.2.1: Allowing only one atom:name in a Person construct is a Bad Thing. Lots of people have different names in different contexts (it's common for Chinese and Chinese-American people to have distinct Chinese and English names, e.g.) Since atom:name is language-sensitive, it should be repeatable. 4.1.1: If the order of child elements in an atom:feed element is meaningless, then it ought to be nailed down by the specification to some fixed arbitrary order (alphabetical or whatever). Doing that simplifies processing, eliminates unnecessary differences between semantically equivalent feed documents, and prevents people from smuggling in semantic information by using some magic ordering of child elements. 4.1.1: Why require an "alternate" atom:link in an atom:feed? This implies that a feed can't be the only version of the content: but conceptually a feed might be completely self-contained, with all the content right in the feed. Weaken MUST to SHOULD, I'd say. 4.1.2: same comment on ordering as 4.1.1. 4.1.3.2: I have my doubts whether the atom:content@type attribute needs a SHOULD. That makes life difficult for people who are repackaging other kinds of feeds or feed-like documents as Atom, because they can't know the type in the general case without attempting to fetch the content. Type should be a totally optional hint. 4.1.3.2: The last graf seems totally arbitrary. What's wrong with incorporating remote text/plain, text/html, or */*-xml documents by reference? In particular, what if they don't yet exist when the feed is created? This graf should be removed. 4.2.6 (editorial): for "SHOULD ... should" read "SHOULD ... SHOULD". 4.2.9 (editorial): The atom:link element is explicitly described as empty, which violates the rules in 6 for foreign element extension. Remove "is an empty element that". -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friends or of thine own were: any man's death diminishes me, because I am involved in mankind, and therefore never send to know for whom the bell tolls; it tolls for thee. --John Donne From owner-atom-syntax@mail.imc.org Fri Apr 22 13:07:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05067 for ; Fri, 22 Apr 2005 13:07:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MGvuYu031001; Fri, 22 Apr 2005 09:57:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MGvuFj030998; Fri, 22 Apr 2005 09:57:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MGvuED030991 for ; Fri, 22 Apr 2005 09:57:56 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3MGvui7002871 for ; Fri, 22 Apr 2005 10:57:56 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IFC00LXZXSJQS@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 22 Apr 2005 10:57:56 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFC002AXXSJUG@mail.sun.net> for atom-syntax@imc.org; Fri, 22 Apr 2005 10:57:55 -0600 (MDT) Date: Fri, 22 Apr 2005 12:19:06 -0400 From: John Cowan Subject: Comments on atompub-format-08 (Modified by Tim Bray) To: Tim.Bray@Sun.COM Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Redirected from John Cowan -Tim ======================================================= I heard about the Last Call via Ongoing, so I'm going to pester you with these rather than doing the Right Thing, because at the moment I'm too swamped to find out what the Right Thing is. Feel free to squelch any of these that have been already discussed to death, or to point me to the Right Thing. 3.2.1: Allowing only one atom:name in a Person construct is a Bad Thing. Lots of people have different names in different contexts (it's common for Chinese and Chinese-American people to have distinct Chinese and English names, e.g.) Since atom:name is language-sensitive, it should be repeatable. 4.1.1: If the order of child elements in an atom:feed element is meaningless, then it ought to be nailed down by the specification to some fixed arbitrary order (alphabetical or whatever). Doing that simplifies processing, eliminates unnecessary differences between semantically equivalent feed documents, and prevents people from smuggling in semantic information by using some magic ordering of child elements. 4.1.1: Why require an "alternate" atom:link in an atom:feed? This implies that a feed can't be the only version of the content: but conceptually a feed might be completely self-contained, with all the content right in the feed. Weaken MUST to SHOULD, I'd say. 4.1.2: same comment on ordering as 4.1.1. 4.1.3.2: I have my doubts whether the atom:content@type attribute needs a SHOULD. That makes life difficult for people who are repackaging other kinds of feeds or feed-like documents as Atom, because they can't know the type in the general case without attempting to fetch the content. Type should be a totally optional hint. 4.1.3.2: The last graf seems totally arbitrary. What's wrong with incorporating remote text/plain, text/html, or */*-xml documents by reference? In particular, what if they don't yet exist when the feed is created? This graf should be removed. 4.2.6 (editorial): for "SHOULD ... should" read "SHOULD ... SHOULD". 4.2.9 (editorial): The atom:link element is explicitly described as empty, which violates the rules in 6 for foreign element extension. Remove "is an empty element that". -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friends or of thine own were: any man's death diminishes me, because I am involved in mankind, and therefore never send to know for whom the bell tolls; it tolls for thee. --John Donne From owner-atom-syntax@mail.imc.org Fri Apr 22 13:29:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06350 for ; Fri, 22 Apr 2005 13:29:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MHL7r7037997; Fri, 22 Apr 2005 10:21:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MHL7j7037996; Fri, 22 Apr 2005 10:21:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MHL5rp037950 for ; Fri, 22 Apr 2005 10:21:06 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3MHIsRg000281; Fri, 22 Apr 2005 18:19:00 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: Comments on atompub-format-08 (Modified by Tim Bray) Date: Fri, 22 Apr 2005 18:19:00 +0100 To: John Cowan X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 22 Apr 2005, at 5:19 pm, John Cowan wrote: > 3.2.1: Allowing only one atom:name in a Person construct is a Bad > Thing. > Lots of people have different names in different contexts (it's common > for Chinese and Chinese-American people to have distinct Chinese and > English names, e.g.) Since atom:name is language-sensitive, it should > be repeatable. How would a client app display multiple names? > 4.1.1: If the order of child elements in an atom:feed element is > meaningless, then it ought to be nailed down by the specification to > some > fixed arbitrary order (alphabetical or whatever). Doing that > simplifies > processing, eliminates unnecessary differences between semantically > equivalent feed documents, and prevents people from smuggling in > semantic > information by using some magic ordering of child elements. Causes unnecessary hassle to implementors. Totally unenforceable. > 4.1.3.2: The last graf seems totally arbitrary. What's wrong with > incorporating remote text/plain, text/html, or */*-xml documents by > reference? In particular, what if they don't yet exist when the feed > is created? This graf should be removed. The idea is that wherever possible content is internal. Also, why are you proposing advertising the existence of files that don't exist? Graham From owner-atom-syntax@mail.imc.org Fri Apr 22 13:50:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08138 for ; Fri, 22 Apr 2005 13:50:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MHgpEi045951; Fri, 22 Apr 2005 10:42:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MHgpFn045950; Fri, 22 Apr 2005 10:42:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MHgp9v045899 for ; Fri, 22 Apr 2005 10:42:51 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc12) with SMTP id <2005042217424501400p5kk8e>; Fri, 22 Apr 2005 17:42:45 +0000 Date: Fri, 22 Apr 2005 11:42:43 -0600 Subject: Repeating atom:name (was Comments on atompub-format-08 (Modified by Tim Bray)) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, April 22, 2005, at 11:19 AM, Graham wrote: > On 22 Apr 2005, at 5:19 pm, John Cowan wrote: >> 3.2.1: Allowing only one atom:name in a Person construct is a Bad >> Thing. >> Lots of people have different names in different contexts (it's common >> for Chinese and Chinese-American people to have distinct Chinese and >> English names, e.g.) Since atom:name is language-sensitive, it should >> be repeatable. > > How would a client app display multiple names? It would choose one based on the user's language preferences or it's language capabilities. I could live with multiple names as long as they have a different xml:lang. I could also live without it, but then I'm not Chinese. I can't imagine many people would use it (other than a billion Chinese ;-), so we wouldn't often see it cause clutter. It wouldn't cause any difficulty in consuming feeds that we don't already have to deal with with other elements. I agree with your other comments. From owner-atom-syntax@mail.imc.org Fri Apr 22 13:57:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08631 for ; Fri, 22 Apr 2005 13:57:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MHp6FG049808; Fri, 22 Apr 2005 10:51:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MHp6Pu049807; Fri, 22 Apr 2005 10:51:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MHp5kJ049784 for ; Fri, 22 Apr 2005 10:51:05 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DP2Iw-0004eL-7h; Fri, 22 Apr 2005 17:51:02 +0000 Message-ID: <42693985.1080903@franklinmint.fm> Date: Fri, 22 Apr 2005 13:51:01 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: Repeating atom:name (was Comments on atompub-format-08 (Modified by Tim Bray)) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > On Friday, April 22, 2005, at 11:19 AM, Graham wrote: > >> On 22 Apr 2005, at 5:19 pm, John Cowan wrote: >> >>> 3.2.1: Allowing only one atom:name in a Person construct is a Bad >>> Thing. >>> Lots of people have different names in different contexts (it's common >>> for Chinese and Chinese-American people to have distinct Chinese and >>> English names, e.g.) Since atom:name is language-sensitive, it should >>> be repeatable. >> >> >> How would a client app display multiple names? > > > It would choose one based on the user's language preferences or it's > language capabilities. "Since atom:name is language-sensitive, it should be repeatable." I don't think so. There is nothing stopping someone from defining an extension element to handle alternate names. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Apr 22 13:57:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08649 for ; Fri, 22 Apr 2005 13:57:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MHith9046813; Fri, 22 Apr 2005 10:44:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MHitDA046812; Fri, 22 Apr 2005 10:44:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.reutershealth.com ([65.246.141.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MHisb7046755 for ; Fri, 22 Apr 2005 10:44:54 -0700 (PDT) (envelope-from jcowan@reutershealth.com) Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3MHimLF007221; Fri, 22 Apr 2005 13:44:48 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 22 Apr 2005 13:44:50 -0400 Date: Fri, 22 Apr 2005 13:44:50 -0400 From: John Cowan To: Graham Cc: atom-syntax Subject: Re: Comments on atompub-format-08 (Modified by Tim Bray) Message-ID: <20050422174450.GB1167@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Graham scripsit: > How would a client app display multiple names? It could pick one in accordance with the user's language preference, and optionally display the others through a UI of some sort. > >4.1.1: If the order of child elements in an atom:feed element is > >meaningless, then it ought to be nailed down by the specification to > >some fixed arbitrary order (alphabetical or whatever). Doing that > >simplifies processing, eliminates unnecessary differences between > >semantically equivalent feed documents, and prevents people from > >smuggling in semantic information by using some magic ordering of > >child elements. > > Causes unnecessary hassle to implementors. Totally unenforceable. What unnecessary hassle? What advantage do implementers get by being free to generate child elements in a random order? And as for unenforceable, it's no more so than any other syntax rule. Is XML well-formedness enforceable? > The idea is that wherever possible content is internal. Also, why are > you proposing advertising the existence of files that don't exist? It decouples the process of creating content from creating feeds. If I know I am going to have a chunk of content here, then I can pick a dereferenceable URI for it and not worry about what the content is until it's time for both to be published. As long as the content exists when the feed is published, all is well. -- John Cowan jcowan@reutershealth.com At times of peril or dubitation, http://www.ccil.org/~cowan Perform swift circular ambulation, http://www.reutershealth.com With loud and high-pitched ululation. From owner-atom-syntax@mail.imc.org Fri Apr 22 14:02:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08885 for ; Fri, 22 Apr 2005 14:02:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MHsw6W051657; Fri, 22 Apr 2005 10:54:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MHswRE051656; Fri, 22 Apr 2005 10:54:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MHsvuU051647 for ; Fri, 22 Apr 2005 10:54:57 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DP2Mf-0004gV-Ki; Fri, 22 Apr 2005 17:54:53 +0000 Message-ID: <42693A6D.9070009@franklinmint.fm> Date: Fri, 22 Apr 2005 13:54:53 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Cowan CC: Graham , atom-syntax Subject: Re: Comments on atompub-format-08 (Modified by Tim Bray) References: <20050422174450.GB1167@skunk.reutershealth.com> In-Reply-To: <20050422174450.GB1167@skunk.reutershealth.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John Cowan wrote: > What unnecessary hassle? What advantage do implementers get by being > free to generate child elements in a random order? And as for unenforceable, > it's no more so than any other syntax rule. Is XML well-formedness enforceable? I'm not aware of any RSS deployment experience demonstrating that such a constraint would be effective. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Apr 22 14:21:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10140 for ; Fri, 22 Apr 2005 14:21:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIA7Pi056044; Fri, 22 Apr 2005 11:10:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MIA70l056043; Fri, 22 Apr 2005 11:10:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIA6w3056016 for ; Fri, 22 Apr 2005 11:10:06 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3MI8H6j019766; Fri, 22 Apr 2005 19:08:26 +0100 (BST) In-Reply-To: <20050422174450.GB1167@skunk.reutershealth.com> References: <20050422174450.GB1167@skunk.reutershealth.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2916af2267d91e44e17ba19d42b7e8bf@mac.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: Comments on atompub-format-08 (Modified by Tim Bray) Date: Fri, 22 Apr 2005 19:08:23 +0100 To: John Cowan X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 22 Apr 2005, at 6:44 pm, John Cowan wrote: > It could pick one in accordance with the user's language preference, > and optionally display the others through a UI of some sort. It's just I've never seen a byline in a newspaper that features more than one name, and that's all the author element is there for. You seem to be approaching at as providing exhaustive biographical information. I don't think it's insensitive to suggest they pick one to be known by in a specific context. > What unnecessary hassle? What advantage do implementers get by being > free to generate child elements in a random order? And as for > unenforceable, > it's no more so than any other syntax rule. Is XML well-formedness > enforceable? How are the two comparable? Badly-formed XML is semantically ambiguous. An atom feed with entries or elements in a different order is semantically exactly the same. If you tell me (or anyone else) I have to memorize and implement an arbitrary order, and are open about it achieving exactly nothing, I am going to ignore you. > It decouples the process of creating content from creating feeds. If > I know I am going to have a chunk of content here, then I can pick a > dereferenceable URI for it and not worry about what the content is > until it's time for both to be published. As long as the content > exists when the feed is published, all is well. And why can't you regenerate the feed with content inserted just before publishing it? I really don't follow what you're trying to achieve here. Graham Parks From owner-atom-syntax@mail.imc.org Fri Apr 22 14:26:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10431 for ; Fri, 22 Apr 2005 14:26:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIGWqs058082; Fri, 22 Apr 2005 11:16:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MIGWrY058081; Fri, 22 Apr 2005 11:16:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIGVPQ058067 for ; Fri, 22 Apr 2005 11:16:31 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DP2hX-0004p2-EX; Fri, 22 Apr 2005 18:16:27 +0000 Message-ID: <42693F7B.9080708@franklinmint.fm> Date: Fri, 22 Apr 2005 14:16:27 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Cowan CC: Graham , atom-syntax Subject: remote content (was: Comments on atompub-format-08 (Modified by Tim Bray)) References: <20050422174450.GB1167@skunk.reutershealth.com> In-Reply-To: <20050422174450.GB1167@skunk.reutershealth.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John Cowan wrote: > Graham scripsit: >>The idea is that wherever possible content is internal. Also, why are >>you proposing advertising the existence of files that don't exist? > > > It decouples the process of creating content from creating feeds. If > I know I am going to have a chunk of content here, then I can pick a > dereferenceable URI for it and not worry about what the content is > until it's time for both to be published. As long as the content > exists when the feed is published, all is well. We've had many people speak up about the SHOULD against remote content. Our own spec covers what consumers should do when it happens, as if to acknowledge there are bound to be many situations where producers will need to do it. I suggest we explain the trade-offs and interoperability issues more fully, and make it clear that consumers have no obligation to process or present remote content in the same manner as local content. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Apr 22 14:38:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11183 for ; Fri, 22 Apr 2005 14:38:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MISjbR062868; Fri, 22 Apr 2005 11:28:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MISjAx062867; Fri, 22 Apr 2005 11:28:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf38.cluster1.charter.net (mxsf38.cluster1.charter.net [209.225.28.165]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MISiov062802 for ; Fri, 22 Apr 2005 11:28:44 -0700 (PDT) (envelope-from ndw@nwalsh.com) Received: from mxip14.cluster1.charter.net (mxip14a.cluster1.charter.net [209.225.28.144]) by mxsf38.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j3MISbjV025496 for ; Fri, 22 Apr 2005 14:28:37 -0400 Received: from 68-112-233-63.dhcp.oxfr.ma.charter.com (HELO localhost) (68.112.233.63) by mxip14.cluster1.charter.net with ESMTP; 22 Apr 2005 14:28:38 -0400 X-Ironport-AV: i="3.92,124,1112587200"; d="scan'208"; a="238940609:sNHT21325078" Received: from ndw by localhost with local (Exim 4.50) id 1DP2tH-0007ah-Im; Fri, 22 Apr 2005 14:28:35 -0400 To: atom-syntax@imc.org CC: John Cowan Subject: Re: Comments on atompub-format-08 (Modified by Tim Bray) References: <7bde7e725ebf119c04ffa34cf82d488d@reutershealth.com> From: Norman Walsh X-URL: http://nwalsh.com/ Date: Fri, 22 Apr 2005 14:28:35 -0400 In-Reply-To: <7bde7e725ebf119c04ffa34cf82d488d@reutershealth.com> (John Cowan's message of "Fri, 22 Apr 2005 12:19:06 -0400") Message-ID: <87vf6esm24.fsf@nwalsh.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable FWIW. / John Cowan was heard to say: | 3.2.1: Allowing only one atom:name in a Person construct is a Bad | Thing. | Lots of people have different names in different contexts (it's common | for Chinese and Chinese-American people to have distinct Chinese and | English names, e.g.) Since atom:name is language-sensitive, it should | be repeatable. Yeah, repeatable and the UI picks one seems reasonable to me. | 4.1.1: If the order of child elements in an atom:feed element is | meaningless, then it ought to be nailed down by the specification to | some | fixed arbitrary order (alphabetical or whatever). Doing that simplifies | processing, eliminates unnecessary differences between semantically | equivalent feed documents, and prevents people from smuggling in | semantic | information by using some magic ordering of child elements. *shrug* I seem to recall lots of discussion about this. I'm inclined to agree with John, but I can live with the status quo. | 4.1.1: Why require an "alternate" atom:link in an atom:feed? | This implies that a feed can't be the only version of the content: | but conceptually a feed might be completely self-contained, with all | the content right in the feed. Weaken MUST to SHOULD, I'd say. Indeed. But we've gone round and round on this too. | 4.1.3.2: The last graf seems totally arbitrary. What's wrong with | incorporating remote text/plain, text/html, or */*-xml documents by | reference? In particular, what if they don't yet exist when the feed | is created? This graf should be removed. I agree. | 4.2.9 (editorial): The atom:link element is explicitly described as | empty, which violates the rules in 6 for foreign element extension. | Remove "is an empty element that". Yep. Be seeing you, norm =2D-=20 Norman Walsh | Almost every man wastes part of his http://nwalsh.com/ | life in attempts to display qualities | which he does not possess, and to gain | applause which he cannot keep.--Dr. | Johnson --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCaUJTOyltUcwYWjsRAnaIAJ9rjPIoyPhsK0Wu83Xl7AlkCCKymACfZTi7 GSgCs85bEzIRXUnHmeo4nW4= =V/tD -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Fri Apr 22 14:43:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11365 for ; Fri, 22 Apr 2005 14:43:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIbl6m065813; Fri, 22 Apr 2005 11:37:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MIblex065810; Fri, 22 Apr 2005 11:37:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.reutershealth.com ([65.246.141.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIbjh6065769 for ; Fri, 22 Apr 2005 11:37:46 -0700 (PDT) (envelope-from jcowan@reutershealth.com) Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3MIbdoH007450; Fri, 22 Apr 2005 14:37:39 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 22 Apr 2005 14:37:40 -0400 Date: Fri, 22 Apr 2005 14:37:39 -0400 From: John Cowan To: Graham Cc: atom-syntax@imc.org Subject: Re: Comments on atompub-format-08 (Modified by Tim Bray) Message-ID: <20050422183739.GC1167@skunk.reutershealth.com> References: <20050422174450.GB1167@skunk.reutershealth.com> <2916af2267d91e44e17ba19d42b7e8bf@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2916af2267d91e44e17ba19d42b7e8bf@mac.com> User-Agent: Mutt/1.4.1i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Graham scripsit: > On 22 Apr 2005, at 6:44 pm, John Cowan wrote: > >It could pick one in accordance with the user's language preference, > >and optionally display the others through a UI of some sort. > > It's just I've never seen a byline in a newspaper that features more > than one name, and that's all the author element is there for. You seem > to be approaching at as providing exhaustive biographical information. I'm not talking about the atom:author element specifically, but about Person constructs in general. > I don't think it's insensitive to suggest they pick one to be known by > in a specific context. I suppose that that's tolerable, considering that the name is uncontrolled text anyway. > >What unnecessary hassle? What advantage do implementers get by being > >free to generate child elements in a random order? And as for > >unenforceable, > >it's no more so than any other syntax rule. Is XML well-formedness > >enforceable? > > How are the two comparable? Badly-formed XML is semantically ambiguous. > An atom feed with entries or elements in a different order is > semantically exactly the same. It's semantically the same until someone decides, as I said in my first email, to attach semantic significance to the order. If the order is fixed, that can't happen. > And why can't you regenerate the feed with content inserted just before > publishing it? I really don't follow what you're trying to achieve > here. The DRY principle is in effect. Why should the content appear in more than one place when there is an Atom-blessed way of making it appear just once? I'm concerned that if this is a SHOULD, feed consumers won't implement it or won't implement it properly. -- Overhead, without any fuss, the stars were going out. --Arthur C. Clarke, "The Nine Billion Names of God" John Cowan From owner-atom-syntax@mail.imc.org Fri Apr 22 14:43:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11400 for ; Fri, 22 Apr 2005 14:43:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIcVmu066047; Fri, 22 Apr 2005 11:38:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MIcV8v066046; Fri, 22 Apr 2005 11:38:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.reutershealth.com ([65.246.141.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIcU40066014 for ; Fri, 22 Apr 2005 11:38:31 -0700 (PDT) (envelope-from jcowan@reutershealth.com) Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3MIcLI8007454; Fri, 22 Apr 2005 14:38:22 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 22 Apr 2005 14:38:32 -0400 Date: Fri, 22 Apr 2005 14:38:32 -0400 From: John Cowan To: Robert Sayre Cc: Graham , atom-syntax Subject: Re: remote content (was: Comments on atompub-format-08 (Modified by Tim Bray)) Message-ID: <20050422183832.GD1167@skunk.reutershealth.com> References: <20050422174450.GB1167@skunk.reutershealth.com> <42693F7B.9080708@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42693F7B.9080708@franklinmint.fm> User-Agent: Mutt/1.4.1i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Robert Sayre scripsit: > I suggest we explain the trade-offs and interoperability issues more > fully, and make it clear that consumers have no obligation to process or > present remote content in the same manner as local content. Fair enough. > Robert Sayre > -- John Cowan www.ccil.org/~cowan www.reutershealth.com jcowan@reutershealth.com SAXParserFactory [is] a hideous, evil monstrosity of a class that should be hung, shot, beheaded, drawn and quartered, burned at the stake, buried in unconsecrated ground, dug up, cremated, and the ashes tossed in the Tiber while the complete cast of Wicked sings "Ding dong, the witch is dead." --Elliotte Rusty Harold on xml-dev From owner-atom-syntax@mail.imc.org Fri Apr 22 14:48:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11688 for ; Fri, 22 Apr 2005 14:48:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIgvV3067598; Fri, 22 Apr 2005 11:42:57 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MIgvnn067597; Fri, 22 Apr 2005 11:42:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.reutershealth.com ([65.246.141.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIguC3067574 for ; Fri, 22 Apr 2005 11:42:56 -0700 (PDT) (envelope-from jcowan@reutershealth.com) Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3MIglNN007488; Fri, 22 Apr 2005 14:42:48 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 22 Apr 2005 14:42:49 -0400 Date: Fri, 22 Apr 2005 14:42:49 -0400 From: John Cowan To: Robert Sayre Cc: atom-syntax@imc.org Subject: Re: Comments on atompub-format-08 (Modified by Tim Bray) Message-ID: <20050422184249.GE1167@skunk.reutershealth.com> References: <20050422174450.GB1167@skunk.reutershealth.com> <42693A6D.9070009@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42693A6D.9070009@franklinmint.fm> User-Agent: Mutt/1.4.1i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Robert Sayre scripsit: > I'm not aware of any RSS deployment experience demonstrating that such a > constraint would be effective. RSS doesn't impose the constraint, so how could there be implementation experience there? There is such experience in the SGML and XML worlds generally, however. The general principle is: If order is significant, the spec needs to be loose to permit the document creator to choose the correct order. If order is not significant, the spec should be tight to reduce pointless and dangerous variability and simplify validation and processing. (It's still true that you can put the string "[blue]" anywhere in a Microsoft Excel cell format to turn it blue, even though the specification says clearly "at the beginning only", because the implementor used a general parsing loop to handle it.) -- John Cowan http://www.reutershealth.com http://www.ccil.org/~cowan .e'osai ko sarji la lojban. Please support Lojban! http://www.lojban.org From owner-atom-syntax@mail.imc.org Fri Apr 22 14:52:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11855 for ; Fri, 22 Apr 2005 14:52:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIgsEo067586; Fri, 22 Apr 2005 11:42:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MIgsv1067585; Fri, 22 Apr 2005 11:42:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIgrEk067579 for ; Fri, 22 Apr 2005 11:42:53 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DP373-00051K-IT; Fri, 22 Apr 2005 18:42:49 +0000 Message-ID: <426945A9.8070807@franklinmint.fm> Date: Fri, 22 Apr 2005 14:42:49 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Cowan CC: Graham , atom-syntax Subject: Re: remote content References: <20050422174450.GB1167@skunk.reutershealth.com> <42693F7B.9080708@franklinmint.fm> <20050422183832.GD1167@skunk.reutershealth.com> In-Reply-To: <20050422183832.GD1167@skunk.reutershealth.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John Cowan wrote: > Robert Sayre scripsit: > > >>I suggest we explain the trade-offs and interoperability issues more >>fully, and make it clear that consumers have no obligation to process or >>present remote content in the same manner as local content. > > > Fair enough. Oh, and drop the SHOULD, in case I wasn't clear. I fully agree with your comments on the relevant sections. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Apr 22 15:02:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12372 for ; Fri, 22 Apr 2005 15:02:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIs2LB071796; Fri, 22 Apr 2005 11:54:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MIs2UA071795; Fri, 22 Apr 2005 11:54:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MIs1XK071789 for ; Fri, 22 Apr 2005 11:54:01 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DP3Hq-00059j-KL; Fri, 22 Apr 2005 18:53:58 +0000 Message-ID: <42694846.80101@franklinmint.fm> Date: Fri, 22 Apr 2005 14:53:58 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Cowan CC: atom-syntax@imc.org Subject: Re: Comments on atompub-format-08 (Modified by Tim Bray) References: <20050422174450.GB1167@skunk.reutershealth.com> <42693A6D.9070009@franklinmint.fm> <20050422184249.GE1167@skunk.reutershealth.com> In-Reply-To: <20050422184249.GE1167@skunk.reutershealth.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John Cowan wrote: > The general principle is: If order is significant, the spec needs to be > loose to permit the document creator to choose the correct order. If > order is not significant, the spec should be tight to reduce pointless > and dangerous variability and simplify validation and processing. Pointless and dangerous variability is part of life for syndication formats, I'm afraid. Defining an order for non-entry elements would be sort of like trying to impose order on the HTML element. I believe the WG decided such a constraint would be futile. Also, it would hurt credibility when trying to enforce more important constraints. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Apr 22 15:56:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18799 for ; Fri, 22 Apr 2005 15:56:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MJnfr1086415; Fri, 22 Apr 2005 12:49:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MJnfRK086414; Fri, 22 Apr 2005 12:49:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fungible9.mail.rice.edu (fungible9-dmfe1.mail.rice.edu [128.42.59.179]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MJnfGt086407 for ; Fri, 22 Apr 2005 12:49:41 -0700 (PDT) (envelope-from dsandler@rice.epostmail.org) Received: from localhost (scan1.mail.rice.edu [128.42.58.160]) by fungible9.mail.rice.edu (Postfix) with ESMTP id 626411DB0F for ; Fri, 22 Apr 2005 14:49:40 -0500 (CDT) Received: from fungible9.mail.rice.edu ([128.42.58.179]) by localhost (scan1.mail.rice.edu [128.42.58.160]) (amavisd-new, port 10024) with LMTP id 01176-01-48 for ; Fri, 22 Apr 2005 14:49:39 -0500 (CDT) Received: from myname (sys08.cs.rice.edu [128.42.129.17]) by fungible9.mail.rice.edu (Postfix) with SMTP id B37DE1DB02 for ; Fri, 22 Apr 2005 14:49:39 -0500 (CDT) In-Reply-To: <20050422183739.GC1167@skunk.reutershealth.com> References: <20050422174450.GB1167@skunk.reutershealth.com> <2916af2267d91e44e17ba19d42b7e8bf@mac.com> <20050422183739.GC1167@skunk.reutershealth.com> Mime-Version: 1.0 (Apple Message framework v622) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <359ace905ee58ba7aad01a0f25f26e8b@rice.epostmail.org> Content-Transfer-Encoding: 7bit Cc: Graham , atom-syntax@imc.org X-Image-Url: http://dsandler.org/art/slashdot/coffee-dude-aim-icon.gif From: Dan Sandler Subject: Re: Comments on atompub-format-08 (Modified by Tim Bray) Date: Fri, 22 Apr 2005 14:49:38 -0500 To: John Cowan X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavis-2.1.2 at scan1.mail.rice.edu Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>> What advantage do implementers get by being free to generate child >>> elements in a random order? >> >> An atom feed with entries or elements in a different order is >> semantically exactly the same. > > It's semantically the same until someone decides, as I said in my > first email, to attach semantic significance to the order. It is possible that this has already occurred: Per section 5.1 of the current draft proposal, Atom feed documents or entry documents may be signed (with an enveloped xmldsig signature). Once signed, the order of the constituent elements suddenly becomes semantically significant: it is the only order for which the signature will be valid. This essentially means that intermediate entities which parse and re-emit Atom feed data (such as aggregators or caches) must remember "semantically meaningless" details, such as the order of elements, in order to re-construct the Atom feed XML in a way that preserves signature validity. > Pointless and dangerous variability is part of life for syndication > formats, I'm afraid. If so, then it sounds to me like it is the specification of signed documents that needs to be changed (to be tolerant of variable element order, as well as other "equivalent" transformations on a document, such as different encoding schemes for ). This may be a weakness of the XML-Signatures specification, especially when applied to Atom; it appears to me that xmldsig was not designed with such "loose" XML document formats in mind. ---dan -- Dan Sandler Rice University http://www.cs.rice.edu/~dsandler/ From owner-atom-syntax@mail.imc.org Fri Apr 22 16:16:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24911 for ; Fri, 22 Apr 2005 16:16:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MK6BXW089606; Fri, 22 Apr 2005 13:06:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MK6B2f089605; Fri, 22 Apr 2005 13:06:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MK69W2089595 for ; Fri, 22 Apr 2005 13:06:10 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1667807wri for ; Fri, 22 Apr 2005 13:06:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OpvIYUFtl6e2DIAih9O8MdJtPdq2DMD/Sxo5VESbB7aCLywfz+7BTOYlm1LrMbgWlQP2LvLMyOjYGYVJzo9VWUOW5gNfxJJcEtU3jRJ2oy2iMJ9CO56A8b8uUxxoiFDSgB+JcdyT3qg8/YkHFBI6nUV55E9sKYsFWVxIzsm87e4= Received: by 10.54.49.34 with SMTP id w34mr650332wrw; Fri, 22 Apr 2005 13:06:04 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Fri, 22 Apr 2005 13:06:04 -0700 (PDT) Message-ID: <540e373205042213067c3698a3@mail.gmail.com> Date: Fri, 22 Apr 2005 15:06:04 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax Subject: Re: Comments on atompub-format-08 (Modified by Tim Bray) In-Reply-To: <20050422174450.GB1167@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050422174450.GB1167@skunk.reutershealth.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3MK6AW2089599 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > What unnecessary hassle? John: Instead of a user dropping a basic Atom 1.0 template into her directory, I would need to add special-case code to the underlying app to get Atom entries into whatever fanciful order the WG settled on. > What advantage do implementers get by being > free to generate child elements in a random order? The order isn't random to the individual implementor. But to put it simply: re-use of queries. -- Roger Benningfield http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Fri Apr 22 16:37:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00666 for ; Fri, 22 Apr 2005 16:37:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MKUAal093257; Fri, 22 Apr 2005 13:30:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MKU9j5093256; Fri, 22 Apr 2005 13:30:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MKU9Kc093250 for ; Fri, 22 Apr 2005 13:30:09 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3MKU9jO012472 for ; Fri, 22 Apr 2005 14:30:09 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IFD007YX7M8CA@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 22 Apr 2005 14:30:08 -0600 (MDT) Received: from [192.168.102.100] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFD00HT57M7JS@mail.sun.net> for atom-syntax@imc.org; Fri, 22 Apr 2005 14:30:08 -0600 (MDT) Date: Fri, 22 Apr 2005 13:30:55 -0700 From: Tim Bray Subject: Re: remote content In-reply-to: <426945A9.8070807@franklinmint.fm> To: Robert Sayre Cc: John Cowan , Graham , atom-syntax Message-id: <50935291a598947a4500ea48b00c3433@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20050422174450.GB1167@skunk.reutershealth.com> <42693F7B.9080708@franklinmint.fm> <20050422183832.GD1167@skunk.reutershealth.com> <426945A9.8070807@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 22, 2005, at 11:42 AM, Robert Sayre wrote: > John Cowan wrote: >> Robert Sayre scripsit: >>> I suggest we explain the trade-offs and interoperability issues more >>> fully, and make it clear that consumers have no obligation to >>> process or present remote content in the same manner as local >>> content. >> Fair enough. > > Oh, and drop the SHOULD, in case I wasn't clear. I fully agree with > your comments on the relevant sections. OK, WG, what do you think? I have long supported the SHOULD here, but I can't help observing that a lot of different parties have questioned it, I'm not 100% sure it really has consensus support, even rough. Rob & John's alternative, as outlined above, seems like a fair trade-off that would better reflect the community consensus and not really harm interoperability. Anybody want to disagree? -TIm From owner-atom-syntax@mail.imc.org Fri Apr 22 16:44:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01109 for ; Fri, 22 Apr 2005 16:44:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MKciji096454; Fri, 22 Apr 2005 13:38:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MKciD7096453; Fri, 22 Apr 2005 13:38:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MKchxi096433 for ; Fri, 22 Apr 2005 13:38:43 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1682274wri for ; Fri, 22 Apr 2005 13:38:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GgRKngEdiKHvM4fAG/QiiXKiY7FYr1wojuWuUksf2h92YfznVc6JGhq+Jujo8vEuZ0ya3hfQ2IsDm2mL7DFR9/H3Mhkt6ofSOeLt5ApBu8CuOqxyxaiqe5yFkMTr+Eb4BLcyQlDFKfMH3I654fDC+b+Y8TgC5shEPVc0J7rBgzQ= Received: by 10.54.21.59 with SMTP id 59mr673323wru; Fri, 22 Apr 2005 13:38:38 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Fri, 22 Apr 2005 13:38:38 -0700 (PDT) Message-ID: <540e373205042213384e26ac2f@mail.gmail.com> Date: Fri, 22 Apr 2005 15:38:38 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax Subject: Re: xml:base and html rendering In-Reply-To: <429ca72206330e34982f9758e3593819@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> <4267CA9C.9020008@dehora.net> <4267CC57.3050100@franklinmint.fm> <4267DAF7.1010400@dehora.net> <4267EB83.1070103@franklinmint.fm> <429ca72206330e34982f9758e3593819@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3MKchxi096447 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Requiring URIs in the content to be absolute to begin with is > too expensive, and probably completely unenforceable. Graham: I suppose that, if nothing else, it's a self-correcting problem. When all those hybrid RSS/Atom parsers out there display broken images or links, most publishers will get a clue and make sure they're putting absolute URIs in their feeds. And if they don't mind broken images and links, well, I guess it wasn't much of a problem in the first place. -- Roger Benningfield http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Fri Apr 22 16:47:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01267 for ; Fri, 22 Apr 2005 16:47:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MKg9CN097312; Fri, 22 Apr 2005 13:42:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MKg9gS097311; Fri, 22 Apr 2005 13:42:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MKg9bY097149 for ; Fri, 22 Apr 2005 13:42:09 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc11) with SMTP id <200504222041330110081c4ae>; Fri, 22 Apr 2005 20:41:33 +0000 Date: Fri, 22 Apr 2005 14:41:31 -0600 Subject: Re: remote content Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <50935291a598947a4500ea48b00c3433@sun.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, April 22, 2005, at 02:30 PM, Tim Bray wrote: > On Apr 22, 2005, at 11:42 AM, Robert Sayre wrote: >> John Cowan wrote: >>> Robert Sayre scripsit: >>>> I suggest we explain the trade-offs and interoperability issues >>>> more fully, and make it clear that consumers have no obligation to >>>> process or present remote content in the same manner as local >>>> content. >>> Fair enough. >> >> Oh, and drop the SHOULD, in case I wasn't clear. I fully agree with >> your comments on the relevant sections. > > OK, WG, what do you think? I have long supported the SHOULD here, but > I can't help observing that a lot of different parties have questioned > it, I'm not 100% sure it really has consensus support, even rough. > Rob & John's alternative, as outlined above, seems like a fair > trade-off that would better reflect the community consensus and not > really harm interoperability. Anybody want to disagree? -TIm > I have a very strong preference for local content, but could live with the above if it is indeed made "clear that consumers have no obligation to process or present remote content". What does "in the same manner as local content" add? It suggests that consumers might be obligated to present or process it in some other way. I'd rather we say that consumers MAY treat the entry as if atom:content were empty if we drop the SHOULD. Antone From owner-atom-syntax@mail.imc.org Fri Apr 22 17:25:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04068 for ; Fri, 22 Apr 2005 17:25:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MLKEr4005605; Fri, 22 Apr 2005 14:20:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MLKExG005604; Fri, 22 Apr 2005 14:20:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MLKDTF005597 for ; Fri, 22 Apr 2005 14:20:13 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-12lcgc7.cable.mindspring.com ([69.86.65.135] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DP5ZJ-0007le-ST; Fri, 22 Apr 2005 21:20:09 +0000 Message-ID: <42696A88.8020501@franklinmint.fm> Date: Fri, 22 Apr 2005 17:20:08 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Sandler CC: atom-syntax@imc.org Subject: DSig (was: Comments on atompub-format-08 (Modified by Tim Bray)) References: <20050422174450.GB1167@skunk.reutershealth.com> <2916af2267d91e44e17ba19d42b7e8bf@mac.com> <20050422183739.GC1167@skunk.reutershealth.com> <359ace905ee58ba7aad01a0f25f26e8b@rice.epostmail.org> In-Reply-To: <359ace905ee58ba7aad01a0f25f26e8b@rice.epostmail.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dan Sandler wrote: > This essentially means that intermediate entities which parse and > re-emit Atom feed data (such as aggregators or caches) must remember > "semantically meaningless" details, such as the order of elements, in > order to re-construct the Atom feed XML in a way that preserves > signature validity. Welcome. Yes, but only if they wish for the signature to remain valid. The Atom spec doesn't require that they preserve signature validity, however. Your post reminded me that I've made a quick little Atom/DSig demo project in NetBeans. There's nothing very special or difficult about it, but it took me a while to figure out the XML Security incantations. Main file: http://franklinmint.fm/2005/04/22/CreateSignedFeed.java.html The NetBeans project: http://franklinmint.fm/2005/04/22/DSigExample.tar.gz Signed feed: http://franklinmint.fm/2005/04/22/signed_feed_example.atom Robert Sayre From owner-atom-syntax@mail.imc.org Fri Apr 22 17:28:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04423 for ; Fri, 22 Apr 2005 17:28:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MLHihE005307; Fri, 22 Apr 2005 14:17:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MLHikO005306; Fri, 22 Apr 2005 14:17:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MLHhak005284 for ; Fri, 22 Apr 2005 14:17:43 -0700 (PDT) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-250.adsl-net.finnetcom.net ([217.140.228.250]:50799 "EHLO [217.140.228.250]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228719AbVDVVRl (ORCPT ); Sat, 23 Apr 2005 00:17:41 +0300 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <87vf6esm24.fsf@nwalsh.com> References: <7bde7e725ebf119c04ffa34cf82d488d@reutershealth.com> <87vf6esm24.fsf@nwalsh.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <083d21761a7760103a607c510199b663@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: Comments on atompub-format-08 (Modified by Tim Bray) Date: Sat, 23 Apr 2005 00:17:24 +0300 To: Atom Syntax X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Apr 22, 2005, at 21:28, Norman Walsh wrote: > / John Cowan was heard to say: > | 3.2.1: Allowing only one atom:name in a Person construct is a Bad > | Thing. > | Lots of people have different names in different contexts (it's > common > | for Chinese and Chinese-American people to have distinct Chinese and > | English names, e.g.) Since atom:name is language-sensitive, it > should > | be repeatable. > > Yeah, repeatable and the UI picks one seems reasonable to me. IMO, it is not reasonable, because it would complicate clients for virtually no practical benefit. If only one name is displayed, why bother with all the hassle for the special case instead of the author deciding which name (s)he feels like using today? If you've got an English name and a Chinese name, use the Chinese name if you are writing Chinese and the English name if you are writing English. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From owner-atom-syntax@mail.imc.org Fri Apr 22 18:11:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08117 for ; Fri, 22 Apr 2005 18:11:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MM43Ng011484; Fri, 22 Apr 2005 15:04:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MM43Jv011483; Fri, 22 Apr 2005 15:04:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fungible5.mail.rice.edu (fungible5-dmfe1.mail.rice.edu [128.42.59.175]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MM40FL011473 for ; Fri, 22 Apr 2005 15:04:02 -0700 (PDT) (envelope-from dsandler@rice.epostmail.org) Received: from localhost (scan1.mail.rice.edu [128.42.58.160]) by fungible5.mail.rice.edu (Postfix) with ESMTP id 9A7A019885 for ; Fri, 22 Apr 2005 17:03:59 -0500 (CDT) Received: from fungible5.mail.rice.edu ([128.42.58.175]) by localhost (scan1.mail.rice.edu [128.42.58.160]) (amavisd-new, port 10024) with LMTP id 09832-01-36 for ; Fri, 22 Apr 2005 17:03:58 -0500 (CDT) Received: from myname (sys08.cs.rice.edu [128.42.129.17]) by fungible5.mail.rice.edu (Postfix) with SMTP id DA50F19892 for ; Fri, 22 Apr 2005 17:03:58 -0500 (CDT) In-Reply-To: <42696A88.8020501@franklinmint.fm> References: <20050422174450.GB1167@skunk.reutershealth.com> <2916af2267d91e44e17ba19d42b7e8bf@mac.com> <20050422183739.GC1167@skunk.reutershealth.com> <359ace905ee58ba7aad01a0f25f26e8b@rice.epostmail.org> <42696A88.8020501@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v622) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6f07403d1d3383747455b47d7b11695f@rice.epostmail.org> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org X-Image-Url: http://dsandler.org/art/slashdot/coffee-dude-aim-icon.gif From: Dan Sandler Subject: Re: DSig (was: Comments on atompub-format-08 (Modified by Tim Bray)) Date: Fri, 22 Apr 2005 17:03:54 -0500 To: Robert Sayre X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavis-2.1.2 at scan1.mail.rice.edu Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: >> This essentially means that intermediate entities which parse and >> re-emit Atom feed data (such as aggregators or caches) must remember >> "semantically meaningless" details, such as the order of elements, in >> order to re-construct the Atom feed XML in a way that preserves >> signature validity. > > Yes, but only if they wish for the signature to remain valid. The Atom > spec doesn't require that they preserve signature validity, however. You're right, the spec doesn't require this. Should it? It seems to me that signed content is most useful when you have received it from some third party instead of the original publisher, and you want to be sure it hasn't been tampered with. These mysterious third parties are currently rare, but that may not be the case forever. There are already a number of "feed republishers" (e.g., FeedBurner) which would need to preserve the validity of feed signatures. Viewed more broadly, any Atom-consuming toolkit which also emits Atom as output (e.g., Rome) would need to pay attention to ordering in order to preserve feed signatures; the spec does not currently require them to do this. [Another example is my current research project, FeedTree[1]. It uses a decentralized event notification system to distribute RSS and Atom data among interested peers, thereby reducing bandwidth demands on publishers and improving promptness of service for end users. In order to establish the authenticity of an Atom entry it has received, each FeedTree node would like to verify the publisher's signature on that item. Some intermediate node might shuffle the order of elements (as a result, say, of parsing the feed and re-emitting it); it has done nothing "wrong" within the Atom specification and yet the signature is broken. For the purposes of FeedTree I'm able to sidestep this issue by using a predictable ordering within the system, but it would be nice if a node were able to take a "wild" signed Atom document and inject it *into* the system in a way that doesn't break signatures.] [1] http://www.cs.rice.edu/~dsandler/pub/FeedTree-IPTPS05-draft.pdf ---dan -- Dan Sandler Rice University http://www.cs.rice.edu/~dsandler/ From owner-atom-syntax@mail.imc.org Fri Apr 22 18:33:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10480 for ; Fri, 22 Apr 2005 18:33:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MMPFJO014888; Fri, 22 Apr 2005 15:25:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MMPFgA014887; Fri, 22 Apr 2005 15:25:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MMPERf014837 for ; Fri, 22 Apr 2005 15:25:15 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc14) with SMTP id <2005042222250801400oehgve>; Fri, 22 Apr 2005 22:25:08 +0000 Date: Fri, 22 Apr 2005 16:25:07 -0600 Subject: Re: DSig (was: Comments on atompub-format-08 (Modified by Tim Bray)) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <42696A88.8020501@franklinmint.fm> Message-Id: <617ACBB4-B37D-11D9-B31F-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dan Sandler wrote: > This essentially means that intermediate entities which parse and > re-emit Atom feed data (such as aggregators or caches) must remember > "semantically meaningless" details, such as the order of elements, in > order to re-construct the Atom feed XML in a way that preserves > signature validity. > More issues: What happens when a signed entry contains foreign markup (aka elements from some other namespace)? If there's just one and we specify a location in the sequence for foreign markup, we're safe, but what if there are two? What about when an Atom element is duplicated (eg. the titles in two languages, two contributors). Are we going specify the order of attributes on elements? (Does that affect the signature?) What about extension attributes on Atom elements? If we can't solve all of these, do we care to solve some of them? From owner-atom-syntax@mail.imc.org Fri Apr 22 18:35:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10771 for ; Fri, 22 Apr 2005 18:35:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MMSI9k015811; Fri, 22 Apr 2005 15:28:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MMSIn5015810; Fri, 22 Apr 2005 15:28:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [165.227.249.220] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MMSBjq015763; Fri, 22 Apr 2005 15:28:12 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <6f07403d1d3383747455b47d7b11695f@rice.epostmail.org> References: <20050422174450.GB1167@skunk.reutershealth.com> <2916af2267d91e44e17ba19d42b7e8bf@mac.com> <20050422183739.GC1167@skunk.reutershealth.com> <359ace905ee58ba7aad01a0f25f26e8b@rice.epostmail.org> <42696A88.8020501@franklinmint.fm> <6f07403d1d3383747455b47d7b11695f@rice.epostmail.org> Date: Fri, 22 Apr 2005 15:28:08 -0700 To: Dan Sandler , Robert Sayre From: Paul Hoffman Subject: Re: DSig (was: Comments on atompub-format-08 (Modified by Tim Bray)) Cc: atom-syntax@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 5:03 PM -0500 4/22/05, Dan Sandler wrote: >Robert Sayre wrote: > >>>This essentially means that intermediate entities which parse and >>>re-emit Atom feed data (such as aggregators or caches) must >>>remember "semantically meaningless" details, such as the order of >>>elements, in order to re-construct the Atom feed XML in a way that >>>preserves signature validity. >> >>Yes, but only if they wish for the signature to remain valid. The >>Atom spec doesn't require that they preserve signature validity, >>however. > >You're right, the spec doesn't require this. Should it? No. A signature is only significant from the signer, not anyone else who touches any of the bits. If you want to touch any of the bits (even just disassembling and reassemling), assume the signature will be broken. > It seems to me that signed content is most useful when you have >received it from some third party instead of the original publisher, >and you want to be sure it hasn't been tampered with. If so, then the third party must handle it as an opaque blob. >These mysterious third parties are currently rare, but that may not >be the case forever. There are already a number of "feed >republishers" (e.g., FeedBurner) which would need to preserve the >validity of feed signatures. Viewed more broadly, any >Atom-consuming toolkit which also emits Atom as output (e.g., Rome) >would need to pay attention to ordering in order to preserve feed >signatures; the spec does not currently require them to do this. They need to pay attention to much more than just the order of the entries to make sure the signature is valid. Every bit, and every bit's order, counts. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Apr 22 18:56:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12010 for ; Fri, 22 Apr 2005 18:56:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MMnILP022250; Fri, 22 Apr 2005 15:49:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3MMnIcr022249; Fri, 22 Apr 2005 15:49:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3MMnHwV022227; Fri, 22 Apr 2005 15:49:17 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3MMnHjO016238; Fri, 22 Apr 2005 16:49:17 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IFD00B0WE2491@edgemail1.Central.Sun.COM>; Fri, 22 Apr 2005 16:49:17 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFD000VXE238A@mail.sun.net>; Fri, 22 Apr 2005 16:49:16 -0600 (MDT) Date: Fri, 22 Apr 2005 15:50:03 -0700 From: Tim Bray Subject: Re: DSig (was: Comments on atompub-format-08 (Modified by Tim Bray)) In-reply-to: To: Paul Hoffman Cc: Dan Sandler , Robert Sayre , atom-syntax@imc.org Message-id: <0b5ecea9c815cead15d0a5c59d443b42@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <20050422174450.GB1167@skunk.reutershealth.com> <2916af2267d91e44e17ba19d42b7e8bf@mac.com> <20050422183739.GC1167@skunk.reutershealth.com> <359ace905ee58ba7aad01a0f25f26e8b@rice.epostmail.org> <42696A88.8020501@franklinmint.fm> <6f07403d1d3383747455b47d7b11695f@rice.epostmail.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 22, 2005, at 3:28 PM, Paul Hoffman wrote: > > They need to pay attention to much more than just the order of the > entries to make sure the signature is valid. Every bit, and every > bit's order, counts. Actually, not really. I think XML DSig specifies canonical XML (right?), so and > > Actually, not really. I think XML DSig specifies canonical XML > (right?), so Yes, > > and > > > will end up with the same DSIG. > > But element order *does* matter. that's correct, but changing Atom draft-07 snapshot to Atom draft-07 snapshot will invalidate the signature, so there are requirements in excess of element order, as far as Atom is concerned. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Apr 23 05:08:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09493 for ; Sat, 23 Apr 2005 05:08:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3N90fkg024217; Sat, 23 Apr 2005 02:00:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3N90fuK024216; Sat, 23 Apr 2005 02:00:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from cmailg2.svr.pol.co.uk (cmailg2.svr.pol.co.uk [195.92.195.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3N90cIr024195 for ; Sat, 23 Apr 2005 02:00:40 -0700 (PDT) (envelope-from lists@isofarro.uklinux.net) Received: from user-3619.lns1-c8.dsl.pol.co.uk ([84.66.174.35] helo=[192.168.0.2]) by cmailg2.svr.pol.co.uk with esmtp (Exim 4.41) id 1DPGV1-0003XC-9t for atom-syntax@imc.org; Sat, 23 Apr 2005 10:00:27 +0100 Message-ID: <426A0E8F.8070705@isofarro.uklinux.net> Date: Sat, 23 Apr 2005 09:59:59 +0100 From: Isofarro User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: draft-8 Issues - atom:head Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just going through draft-8 at the moment, setting up some PHP classes. 4.2.4 The "atom:copyright" Element ----------------------------------- "If an atom:entry element does not contain an atom:copyright element, then the atom:copyright element of the containing atom:feed element's atom:head element, if present, is considered to apply to the entry." Remove reference to "atom:head element" Mike. From owner-atom-syntax@mail.imc.org Sat Apr 23 07:30:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17766 for ; Sat, 23 Apr 2005 07:30:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3NBLkcP084989; Sat, 23 Apr 2005 04:21:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3NBLk1s084988; Sat, 23 Apr 2005 04:21:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta05-winn.mailhost.ntl.com (smtpout15.mailhost.ntl.com [212.250.162.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3NBLiNn084926 for ; Sat, 23 Apr 2005 04:21:44 -0700 (PDT) (envelope-from djpowell@djpowell.net) Received: from aamta01-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050423112138.UVO29397.mta05-winn.mailhost.ntl.com@aamta01-winn.mailhost.ntl.com>; Sat, 23 Apr 2005 12:21:38 +0100 Received: from cpc3-stok1-5-0-cust172.bagu.cable.ntl.com ([82.11.128.172]) by aamta01-winn.mailhost.ntl.com with ESMTP id <20050423112138.JYHH1187.aamta01-winn.mailhost.ntl.com@cpc3-stok1-5-0-cust172.bagu.cable.ntl.com>; Sat, 23 Apr 2005 12:21:38 +0100 Date: Sat, 23 Apr 2005 12:21:35 +0100 From: David Powell X-Mailer: The Bat! (v3.0.9.18 Return) Professional X-Priority: 3 (Normal) Message-ID: <1494730745.20050423122135@djpowell.net> To: Eric Scheid CC: Atom Syntax Subject: Re: text/plain Base64? In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sunday, April 10, 2005, 5:48:54 AM, Eric Scheid wrote: > I know content with @type != text/* or */xml *+xml MUST be Base64 encoded, > but what about content with those magic types ... should the spec say that > they MUST NOT be Base64 encoded? Nobody ever answered this. It's just a minor point, but I think that the answer is "yes". -- Dave From owner-atom-syntax@mail.imc.org Sat Apr 23 17:30:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26148 for ; Sat, 23 Apr 2005 17:30:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3NLLZeA067831; Sat, 23 Apr 2005 14:21:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3NLLZnf067830; Sat, 23 Apr 2005 14:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3NLLYDm067822 for ; Sat, 23 Apr 2005 14:21:34 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr10.xs4all.nl (8.12.11/8.12.11) with ESMTP id j3NLLRfq045001 for ; Sat, 23 Apr 2005 23:21:33 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <426ABC49.2060407@w3future.com> Date: Sat, 23 Apr 2005 23:21:13 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> <4267CA9C.9020008@dehora.net> <4267CC57.3050100@franklinmint.fm> <4267DAF7.1010400@dehora.net> <4267EB83.1070103@franklinmint.fm> <429ca72206330e34982f9758e3593819@mac.com> <540e373205042213384e26ac2f@mail.gmail.com> In-Reply-To: <540e373205042213384e26ac2f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roger B. wrote: >>Requiring URIs in the content to be absolute to begin with is >>too expensive, and probably completely unenforceable. > > > Graham: I suppose that, if nothing else, it's a self-correcting > problem. When all those hybrid RSS/Atom parsers out there display > broken images or links, most publishers will get a clue and make sure > they're putting absolute URIs in their feeds. > > And if they don't mind broken images and links, well, I guess it > wasn't much of a problem in the first place. You are right. RSS has this problem already, and it isn't really that much of a problem, just a slight annoyance. As aggregators I've only ever used Radio Userland and Bloglines, and they both don't resolve relative URIs correctly. But there still are plenty of RSS feeds with relative URIs in them. The workaround as user is to simply follow the link to the item first, and then click the link there on the original page. The only thing that changes with xml:base support in Atom is that aggregators who *do* resolve relative URIs, now have more chance to get the originally intended base URI. And a side effect is apparently that aggregator writers are alerted to the relative URI problem, instead of just staying ignorant about it. -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Sun Apr 24 06:08:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03954 for ; Sun, 24 Apr 2005 06:08:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3O9u64j006284; Sun, 24 Apr 2005 02:56:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3O9u6q1006283; Sun, 24 Apr 2005 02:56:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3O9u4ma006242 for ; Sun, 24 Apr 2005 02:56:05 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 24 Apr 2005 09:55:58 -0000 Received: from p508FF280.dip.t-dialin.net (EHLO [192.168.0.4]) [80.143.242.128] by mail.gmx.net (mp011) with SMTP; 24 Apr 2005 11:55:58 +0200 X-Authenticated: #1915285 Message-ID: <426B6D24.7040406@gmx.de> Date: Sun, 24 Apr 2005 11:55:48 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax@imc.org Subject: Issues with draft -08, Re: I-D ACTION:draft-ietf-atompub-format-08.txt References: <200504191938.PAA12867@ietf.org> <42656427.5080709@franklinmint.fm> In-Reply-To: <42656427.5080709@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, I just reviewed my issues list, and here's an editorial one remaining...: 05-E08, 4.6.2 rel attribute 06: "...same name registered within the IANA Registry of Link Relations Section 9, and..." Put the section reference into brackets. Also, I really think that we should do something about the link/rel=alternate issue. Requiring additional metadata that sometimes doesn't exist (such as if the feed is self-contained) IMHO leeds to implementors to ignore the requirement, or to just put in a placeholder link (which doesn't help either). See discussion starting here...: . Best regards, Julian From owner-atom-syntax@mail.imc.org Sun Apr 24 07:37:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09149 for ; Sun, 24 Apr 2005 07:37:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3O7rsZp067837; Sun, 24 Apr 2005 00:53:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3O7rske067836; Sun, 24 Apr 2005 00:53:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailserv2.fla.fujitsu.com (mailserv2.fla.fujitsu.com [128.8.244.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3O7rrbF067784 for ; Sun, 24 Apr 2005 00:53:53 -0700 (PDT) (envelope-from lists@atrus.org) Received: from [129.2.249.50] (zaphod.student.umd.edu [129.2.249.50]) (authenticated bits=0) by mailserv2.fla.fujitsu.com with ESMTP id j3O7rhYr021187 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 24 Apr 2005 03:53:44 -0400 (EDT) Message-ID: <426B513F.3000909@atrus.org> Date: Sun, 24 Apr 2005 03:56:47 -0400 From: "Nikolas 'Atrus' Coukouma" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: robots processing instruction (was NoIndex, again) References: <4265C944.6000704@atrus.org> <4265EB74.2050505@atrus.org> <4265FAEF.7080506@atrus.org> In-Reply-To: <4265FAEF.7080506@atrus.org> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I've revived the robot processing instruction at a (P)URL. It's been rewritten/updated, too. The draft I wrote [2] attempts to address my major concerns with the old version: 1) the "noarchive" instruction seems to be popular and is generally useful; it is now included 2) you no longer have to specify all parameters. omitted values are assumed to be "yes" 3) there's now room for extension by bots in specific realms (e.g. Google's nosnippet) 4) links are no longer specified to be members of the XLink standard I'm a bit concerned about the last two. Including un-namespaced extensiblity creats the potential for conflicts and confusion. I don't have a solution. At least limiting the values to "yes" and "no" prevents people from sneaking content in. I simply left "links" underspecified. Although the XLink standard has stabilized, it's not widely used. Many formats simply treat elements and properties in their own namespaces as links (e.g. the XHTML anchor element). My current philosophy is that links are whatever a bot follows. Comments are not only welcome; they're encouraged. [1] http://purl.org/net/robotspi/ [2] http://purl.org/net/robotspi/spec-20050423/ From owner-atom-syntax@mail.imc.org Sun Apr 24 09:49:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16283 for ; Sun, 24 Apr 2005 09:49:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3ODdQmC083122; Sun, 24 Apr 2005 06:39:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3ODdQiQ083121; Sun, 24 Apr 2005 06:39:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3ODdOBw083094 for ; Sun, 24 Apr 2005 06:39:25 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.33.105]) by smtp.cegetel.net (Postfix) with ESMTP id DE0D222C1FA; Sun, 24 Apr 2005 15:39:18 +0200 (CEST) Message-ID: <426BA185.6030709@cegetel.net> Date: Sun, 24 Apr 2005 15:39:17 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Sjoerd Visscher Cc: atom-syntax Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> <4267CA9C.9020008@dehora.net> <4267CC57.3050100@franklinmint.fm> <4267DAF7.1010400@dehora.net> <4267EB83.1070103@franklinmint.fm> <429ca72206330e34982f9758e3593819@mac.com> <540e373205042213384e26ac2f@mail.gmail.com> <426ABC49.2060407@w3future.com> In-Reply-To: <426ABC49.2060407@w3future.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sjoerd Visscher wrote: > The only thing that changes with xml:base support in Atom is that > aggregators who *do* resolve relative URIs, now have more chance to get > the originally intended base URI. But the Atom spec says: [ Any element defined by this specification MAY have an xml:base attribute. XML Base [W3C.REC-xmlbase-20010627] processing MUST be applied to any relative reference [RFC3987] present in an Atom Document. This includes such elements and attributes as specified by Atom itself, as well as those specified by extensions to Atom. ] *All* aggregators MUST resolve any relative URI reference. We could narrow the XML Base "MUST" scope only to "the elements and attributes as specified by Atom itself, as well as those specified by extensions to Atom" and use a MAY or SHOULD for references found in HTML and XHTML (in text constructs and atom:content) as well as inline foreign content (in atom:content). -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sun Apr 24 10:19:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20007 for ; Sun, 24 Apr 2005 10:19:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OEAJcq088080; Sun, 24 Apr 2005 07:10:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3OEAJCM088079; Sun, 24 Apr 2005 07:10:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OEAImB088071 for ; Sun, 24 Apr 2005 07:10:18 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.33.105]) by smtp.cegetel.net (Postfix) with ESMTP id 50FE4318282; Sun, 24 Apr 2005 16:10:12 +0200 (CEST) Message-ID: <426BA8C4.6010903@cegetel.net> Date: Sun, 24 Apr 2005 16:10:12 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: David Powell Cc: atom-syntax@imc.org Subject: Re: Base URI and link rel="self" References: <1927.82.127.77.43.1114153616.squirrel@ssl-webmail.sitadelle.com> <43988300.20050422085820@djpowell.net> In-Reply-To: <43988300.20050422085820@djpowell.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Powell wrote: > Friday, April 22, 2005, 8:06:56 AM, Thomas Broyer wrote: >> Here's one more question: when a feed have no xml:base, it's base >> URI is the URI from where is has been retrieved. > > Don't forget that the Content-Location header overrides the document > URI if it is present. Yes, I forgot that. So let's say the document URI (used as the base URI when not overridden using xml:base) is set by the transport protocol, which changes nothing to problem. >> should Atom mandate (or otherwise strongly recommend) using an >> xml:base attribute as soon as the feed uses relative URIs? > > It still doesn't solve all of the problems though: Even if you know > the base-URI of an entry, it can still be different to other entries, > from the same feed, and from other feeds, so to display these > together on an HTML page you would need to rewrite the HTML document > with resolved links. I wasn't talking about relative references especially in embedded (X)HTML content but any Atom-defined or extension element or attribute, e.g. atom:image@src, atom:link@href, atom:content@src, etc. As I already said, base URI processing is a larger problem than just rendering several entries in the same HTML document. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sun Apr 24 11:35:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27442 for ; Sun, 24 Apr 2005 11:35:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OFRL5v094743; Sun, 24 Apr 2005 08:27:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3OFRLWH094742; Sun, 24 Apr 2005 08:27:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OFRJJZ094735 for ; Sun, 24 Apr 2005 08:27:20 -0700 (PDT) (envelope-from sjoerd@w3future.com) Received: from [10.0.0.2] (w3future.xs4all.nl [213.84.155.207]) (authenticated bits=0) by smtp-vbr15.xs4all.nl (8.12.11/8.12.11) with ESMTP id j3OFRBxs033177; Sun, 24 Apr 2005 17:27:11 +0200 (CEST) (envelope-from sjoerd@w3future.com) Message-ID: <426BBABF.30009@w3future.com> Date: Sun, 24 Apr 2005 17:26:55 +0200 From: Sjoerd Visscher User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Broyer CC: atom-syntax Subject: Re: xml:base and html rendering References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> <4267CA9C.9020008@dehora.net> <4267CC57.3050100@franklinmint.fm> <4267DAF7.1010400@dehora.net> <4267EB83.1070103@franklinmint.fm> <429ca72206330e34982f9758e3593819@mac.com> <540e373205042213384e26ac2f@mail.gmail.com> <426ABC49.2060407@w3future.com> <426BA185.6030709@cegetel.net> In-Reply-To: <426BA185.6030709@cegetel.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thomas Broyer wrote: > Sjoerd Visscher wrote: > >> The only thing that changes with xml:base support in Atom is that >> aggregators who *do* resolve relative URIs, now have more chance to >> get the originally intended base URI. > > *All* aggregators MUST resolve any relative URI reference. All aggregators must resolve relative URI references in RSS too to work properly. So with Atom the aggregators are broken according to spec, with RSS the aggregators are broken according to practice. Who cares about that difference? -- Sjoerd Visscher http://w3future.com/weblog/ From owner-atom-syntax@mail.imc.org Sun Apr 24 11:35:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27554 for ; Sun, 24 Apr 2005 11:35:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OFST3o094788; Sun, 24 Apr 2005 08:28:29 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3OFSTWS094787; Sun, 24 Apr 2005 08:28:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3OFSSHV094780 for ; Sun, 24 Apr 2005 08:28:28 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3OFSRjO010816 for ; Sun, 24 Apr 2005 09:28:27 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IFG00BNTIZFQF@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 24 Apr 2005 09:28:27 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFG00A7SIZEOI@mail.sun.net> for atom-syntax@imc.org; Sun, 24 Apr 2005 09:28:27 -0600 (MDT) Date: Sun, 24 Apr 2005 08:29:16 -0700 From: Tim Bray Subject: Re: xml:base and html rendering In-reply-to: <426BA185.6030709@cegetel.net> To: Thomas Broyer Cc: atom-syntax , Sjoerd Visscher Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <1114079953.426782d12c7a5@webmail.djpowell.net> <42679095.4060702@dehora.net> <42679BF8.5080100@franklinmint.fm> <4267ACC9.9030908@dehora.net> <87k6mw88eu.fsf@nwalsh.com> <4267CA9C.9020008@dehora.net> <4267CC57.3050100@franklinmint.fm> <4267DAF7.1010400@dehora.net> <4267EB83.1070103@franklinmint.fm> <429ca72206330e34982f9758e3593819@mac.com> <540e373205042213384e26ac2f@mail.gmail.com> <426ABC49.2060407@w3future.com> <426BA185.6030709@cegetel.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 24, 2005, at 6:39 AM, Thomas Broyer wrote: > We could narrow the XML Base "MUST" scope only to "the elements and > attributes as specified by Atom itself, as well as those specified by > extensions to Atom" and use a MAY or SHOULD for references found in > HTML and XHTML (in text constructs and atom:content) as well as inline > foreign content (in atom:content). I don't think there should be any ambiguity here. The language should be changed to say "When xml:base is used in an Atom document, it serves the function described in section 5.1.1 of RFC3986, establishing the base URI for resolving any relative URI references found within the effective scope of the xml:base attribute." This makes it clear that if there is an xml:base whose scope includes , then yes indeed, the intent is to establish a base URI for the content. One of my main gripes about RSS is that it has no rules, so you effectively can't use relative URIs, thus ruling out a common good Web practice. I see clarity on this front as one of the practical advantages offered by Atom. -Tim From owner-atom-syntax@mail.imc.org Mon Apr 25 01:05:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20407 for ; Mon, 25 Apr 2005 01:05:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P4uuop096673; Sun, 24 Apr 2005 21:56:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3P4uucc096672; Sun, 24 Apr 2005 21:56:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P4utXU096655 for ; Sun, 24 Apr 2005 21:56:55 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by mail.pubsub.com (Postfix) with ESMTP id 6938772406A; Mon, 25 Apr 2005 00:56:49 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'John Cowan'" , "'Graham'" Cc: "'atom-syntax'" Subject: Advertising not-yet-existent files... (was Re: Comments on atompub-format-08 (Modified by Tim Bray)) Date: Mon, 25 Apr 2005 00:56:42 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050422174450.GB1167@skunk.reutershealth.com> Thread-Index: AcVHZmso6KpESYNmRuG+u5+a102MCwB6HKqw Message-Id: <20050425045649.6938772406A@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John Cowan wrote in response to Graham: >> The idea is that wherever possible content is internal. Also, why are >> you proposing advertising the existence of files that don't exist? > It decouples the process of creating content from creating feeds. > If I know I am going to have a chunk of content here, then I can > pick a dereferenceable URI for it and not worry about what the content > is until it's time for both to be published. As long as the content > exists when the feed is published, all is well. A slightly different case, but instructive: At PubSub, we have a situation where we regularly publish data in Atom feeds even though the "alternate" pages aren't yet available on the network. This happens constantly with our Earthquake feeds[1]. While each entry we publish has most of the relevant information on an earthquake, each entry also points to pages on the USGS site. The USGS pages provide augmented information concerning the earthquake event in HTML. The problem is that we regularly publish entries in our feeds at least 15 seconds before and sometimes a few minutes before the corresponding pages are available on the USGS site. Their content management system is a bit slower then ours is... What we've had to do is get the USGS folk to change their "page not found" message so that it says: "The webpage you are looking for has either moved or may still be in preparation if it describes a recent earthquake." You can see this message at: http://earthquake.usgs.gov/recenteqsUS/Quakes/nosuchpage.htm Most polling-based readers will not, of course, ever come across this timing problem since their polling frequencies are vastly larger then the 15 second normal publication delay. However, users of push-based Atom readers (like the "Atom over XMPP" based Sidebars[2] that we supply to PubSub users) will often see and click on a new Atom entry from PubSub within two to three seconds of our having published the entry. (Yes, this makes this an edge case; however, as push-based consumption of Atom increases, it will become more common.) Admittedly, publishing real-time, volatile data is not yet a common usage of Atom and push-based Atom consumers are still not common. However, I think we're going to see more of this in the future. Certainly, we at PubSub expect to generate more such feeds and we're certainly going to try to get more people using push-protocols. The difficulty is that delaying publishing until all the alternates or referenced URIs are known to exist imposes unacceptable constraints on the system. With data like Earthquake or Tsunami notices, we should *not* be delaying the publishing of messages simply to conform to the specification... bob wyman [1] http://www.pubsub.com/earthquakes.php [2] http://www.pubsub.com/downloads.php From owner-atom-syntax@mail.imc.org Mon Apr 25 01:08:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20622 for ; Mon, 25 Apr 2005 01:08:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P4vd4o096765; Sun, 24 Apr 2005 21:57:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3P4vd6D096764; Sun, 24 Apr 2005 21:57:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P4vcgK096757 for ; Sun, 24 Apr 2005 21:57:38 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j3P4vbqp027466 for ; Mon, 25 Apr 2005 00:57:37 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DAC76607; Mon, 25 Apr 2005 00:57:36 -0400 (EDT) Message-Id: <200504250457.DAC76607@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'atom-syntax'" Subject: Advertising not-yet-existent files... (was Re: Comments on atompub-format-08 (Modified by Tim Bray)) Date: Mon, 25 Apr 2005 00:57:32 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVHZmso6KpESYNmRuG+u5+a102MCwB6HKqwAAEVaoA= Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John Cowan wrote in response to Graham: >> The idea is that wherever possible content is internal. Also, why are >> you proposing advertising the existence of files that don't exist? > It decouples the process of creating content from creating feeds. > If I know I am going to have a chunk of content here, then I can > pick a dereferenceable URI for it and not worry about what the content > is until it's time for both to be published. As long as the content > exists when the feed is published, all is well. A slightly different case, but instructive: At PubSub, we have a situation where we regularly publish data in Atom feeds even though the "alternate" pages aren't yet available on the network. This happens constantly with our Earthquake feeds[1]. While each entry we publish has most of the relevant information on an earthquake, each entry also points to pages on the USGS site. The USGS pages provide augmented information concerning the earthquake event in HTML. The problem is that we regularly publish entries in our feeds at least 15 seconds before and sometimes a few minutes before the corresponding pages are available on the USGS site. Their content management system is a bit slower then ours is... What we've had to do is get the USGS folk to change their "page not found" message so that it says: "The webpage you are looking for has either moved or may still be in preparation if it describes a recent earthquake." You can see this message at: http://earthquake.usgs.gov/recenteqsUS/Quakes/nosuchpage.htm Most polling-based readers will not, of course, ever come across this timing problem since their polling frequencies are vastly larger then the 15 second normal publication delay. However, users of push-based Atom readers (like the "Atom over XMPP" based Sidebars[2] that we supply to PubSub users) will often see and click on a new Atom entry from PubSub within two to three seconds of our having published the entry. (Yes, this makes this an edge case; however, as push-based consumption of Atom increases, it will become more common.) Admittedly, publishing real-time, volatile data is not yet a common usage of Atom and push-based Atom consumers are still not common. However, I think we're going to see more of this in the future. Certainly, we at PubSub expect to generate more such feeds and we're certainly going to try to get more people using push-protocols. The difficulty is that delaying publishing until all the alternates or referenced URIs are known to exist imposes unacceptable constraints on the system. With data like Earthquake or Tsunami notices, we should *not* be delaying the publishing of messages simply to conform to the specification... bob wyman [1] http://www.pubsub.com/earthquakes.php [2] http://www.pubsub.com/downloads.php From owner-atom-syntax@mail.imc.org Mon Apr 25 02:25:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16119 for ; Mon, 25 Apr 2005 02:25:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P6HVNP037004; Sun, 24 Apr 2005 23:17:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3P6HUMD037002; Sun, 24 Apr 2005 23:17:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P6HUar036983 for ; Sun, 24 Apr 2005 23:17:30 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j3P6HTmm012032; Mon, 25 Apr 2005 02:17:29 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DAC93067; Mon, 25 Apr 2005 02:17:27 -0400 (EDT) Message-Id: <200504250617.DAC93067@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Graham'" , "'John Cowan'" Cc: "'atom-syntax'" Subject: RE: Comments on atompub-format-08 (Modified by Tim Bray) Date: Mon, 25 Apr 2005 02:17:23 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <2916af2267d91e44e17ba19d42b7e8bf@mac.com> Thread-Index: AcVHcFlMG9Hir1h9TD6Kq8mLqYob2wB7NL/w Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > It's just I've never seen a byline in a newspaper that features > more than one name, and that's all the author element is there for. See: Rice and Cheney Are Said to Push Iraqi Politicians on Stalemate By RICHARD A. OPPEL Jr. and JOEL BRINKLEY http://www.nytimes.com/2005/04/25/international/middleeast/25iraq.html? See: "Blogs Will Change Your Business" By Stephen Baker and Heather Green http://businessweek.com/magazine/content/05_18/b3931001_mz001.htm That's one example from a newspaper and one from a magazine. Now, you've seen something that you've never seen before! bob wyman From owner-atom-syntax@mail.imc.org Mon Apr 25 02:46:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17930 for ; Mon, 25 Apr 2005 02:46:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P6d2jE046087; Sun, 24 Apr 2005 23:39:02 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3P6d2v3046086; Sun, 24 Apr 2005 23:39:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P6cxuY046056 for ; Sun, 24 Apr 2005 23:39:01 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j3P6cuTh007196; Mon, 25 Apr 2005 02:38:56 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DAC97052; Mon, 25 Apr 2005 02:38:54 -0400 (EDT) Message-Id: <200504250638.DAC97052@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Julian Reschke'" , "'Robert Sayre'" Cc: Subject: Placeholder alternate links (was: RE: Issues with draft -08, Re: I-D ACTION:draft-ietf-atompub-format-08.txt) Date: Mon, 25 Apr 2005 02:38:50 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <426B6D24.7040406@gmx.de> Thread-Index: AcVItqM/H7ttJAbsT0K5PtNroKcBPwAqYN5A Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Rescke wrote: > I really think that we should do something about the > link/rel=alternate issue. Requiring additional metadata that > sometimes doesn't exist (such as if the feed is self-contained) IMHO > leeds to implementors to ignore the requirement, or to just put in > a placeholder link (which doesn't help either). Every PubSub Atom Feed Document contains a fake "placeholder" link with rel="alternate". The same will probably be true for any system that provides feed documents as the result of queries. Our fake alternate links look like: All of our feeds contain style files that allow them to be rendered in browsers; however, we don't produce HTML equivalents of our feeds. Thus, we can't put in a "real" alternate link, especially not one with "text/html" or the potentially better "application/html" since the type of the only representation of our feeds is "application/xml" not HTML... I can't imagine any search or matching application doing this any differently. Thus, Julian's suggestion that placeholder links *might* be provided is actually simply inevitable. Every one of our feed documents starts like this: 2005-04-25T02:20:56-04:00 PubSub Feed Generator 369 d9/e6/4eb045b8ddaf1923b44b049753 <![CDATA[PubSub: Topix]]> bob wyman From owner-atom-syntax@mail.imc.org Mon Apr 25 03:08:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19754 for ; Mon, 25 Apr 2005 03:08:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P6skSH053917; Sun, 24 Apr 2005 23:54:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3P6skPQ053916; Sun, 24 Apr 2005 23:54:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P6skdm053905 for ; Sun, 24 Apr 2005 23:54:46 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j3P6semo021872; Mon, 25 Apr 2005 02:54:44 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DAD00305; Mon, 25 Apr 2005 02:54:39 -0400 (EDT) Message-Id: <200504250654.DAD00305@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Robert Sayre'" , "'Dan Sandler'" Cc: Subject: RE: DSig (was: Comments on atompub-format-08 (Modified by Tim Bray)) Date: Mon, 25 Apr 2005 02:54:34 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <42696A88.8020501@franklinmint.fm> Thread-Index: AcVHgjuHv4PKvl8cSGOL1LAAtEEhFwB3/1nA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dan Sandler wrote: > This essentially means that intermediate entities which parse and > re-emit Atom feed data (such as aggregators or caches) must remember > "semantically meaningless" details, such as the order of elements, in > order to re-construct the Atom feed XML in a way that preserves > signature validity. One other *significant* limitation in Atom's support for signatures is that there is no way for an intermediary to add to or otherwise modify an Atom entry without breaking the signature. What this means is that intermediaries like PubSub, if they modify an entry by adding content, repairing broken syntax, or normalizing character sets will be forced to remove the original signature and insert a new signature issued by the intermediary. Similar issues will arise in any case where someone copies a signed Atom entry from one feed to another. Unless the copying is done in such a way that it doesn't disturb the canonicalized form of the entry, the original signature will be invalidated. There are numerous other issues relating to signed Atom documents that we've decided (somewhat unwisely...) to punt until after the core document is released. The existing signature support is vitally important to have in the core, however, I feel it really *must* be expanded upon extensively in future extensions. bob wyman From owner-atom-syntax@mail.imc.org Mon Apr 25 03:28:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20950 for ; Mon, 25 Apr 2005 03:28:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P7IiIF064556; Mon, 25 Apr 2005 00:18:44 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3P7Ii0N064555; Mon, 25 Apr 2005 00:18:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P7Igrg064528 for ; Mon, 25 Apr 2005 00:18:43 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 25 Apr 2005 17:18:33 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 25 Apr 2005 17:18:36 +1000 Subject: Re: Comments on atompub-format-08 (Modified by Tim Bray) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <200504250617.DAC93067@ms8.netsolmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 25/4/05 4:17 PM, "Bob Wyman" wrote: > Graham Parks wrote: >> It's just I've never seen a byline in a newspaper that features >> more than one name, and that's all the author element is there for. > > See: Rice and Cheney Are Said to Push Iraqi Politicians on Stalemate > By RICHARD A. OPPEL Jr. and JOEL BRINKLEY > http://www.nytimes.com/2005/04/25/international/middleeast/25iraq.html? > > See: "Blogs Will Change Your Business" > By Stephen Baker and Heather Green > http://businessweek.com/magazine/content/05_18/b3931001_mz001.htm > > > That's one example from a newspaper and one from a magazine. Now, you've > seen something that you've never seen before! Those are examples of multiple authors, not of singular authors with multiple names. Different issue. Not to say multiple authors (not contributors) is not another issue. e. From owner-atom-syntax@mail.imc.org Mon Apr 25 05:00:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26545 for ; Mon, 25 Apr 2005 05:00:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P8leOX098746; Mon, 25 Apr 2005 01:47:40 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3P8le0J098745; Mon, 25 Apr 2005 01:47:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3P8ldVN098678 for ; Mon, 25 Apr 2005 01:47:39 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3P8k37C029113; Mon, 25 Apr 2005 09:46:08 +0100 (BST) In-Reply-To: <200504250617.DAC93067@ms8.netsolmail.com> References: <200504250617.DAC93067@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <893e0b15812514d5ef45332ff613236e@mac.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: Comments on atompub-format-08 (Modified by Tim Bray) Date: Mon, 25 Apr 2005 09:45:48 +0100 To: bob@wyman.us X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 25 Apr 2005, at 7:17 am, Bob Wyman wrote: > Graham Parks wrote: >> It's just I've never seen a byline in a newspaper that features >> more than one name, and that's all the author element is there for. > > See: Rice and Cheney Are Said to Push Iraqi Politicians on Stalemate > By RICHARD A. OPPEL Jr. and JOEL BRINKLEY > http://www.nytimes.com/2005/04/25/international/middleeast/25iraq.html? > > See: "Blogs Will Change Your Business" > By Stephen Baker and Heather Green > http://businessweek.com/magazine/content/05_18/b3931001_mz001.htm Those are different people aren't they? The topic was more than one name for the same person. Never mind Bob. Graham From owner-atom-syntax@mail.imc.org Mon Apr 25 09:33:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15496 for ; Mon, 25 Apr 2005 09:33:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PDNgTr003697; Mon, 25 Apr 2005 06:23:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PDNg7A003696; Mon, 25 Apr 2005 06:23:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PDNfo4003689 for ; Mon, 25 Apr 2005 06:23:41 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf7uk.cable.mindspring.com ([24.215.159.212] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DQ3Yi-0002JT-Bc; Mon, 25 Apr 2005 13:23:32 +0000 Message-ID: <426CEF53.4080007@franklinmint.fm> Date: Mon, 25 Apr 2005 09:23:31 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Dan Sandler'" , atom-syntax@imc.org Subject: Re: DSig (was: Comments on atompub-format-08 (Modified by Tim Bray)) References: <200504250654.DAD00305@ms8.netsolmail.com> In-Reply-To: <200504250654.DAD00305@ms8.netsolmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > One other *significant* limitation in Atom's support for signatures > is that there is no way for an intermediary to add to or otherwise modify an > Atom entry without breaking the signature. If people want to send out signed entries with an XPath filter[0] that gives intermediaries a place to put things, there's nothing stopping them. If they don't want PubSub or equivalent to touch a single bit, that's their prerogative. Robert Sayre [0] http://www.w3.org/TR/xmldsig-filter2/ From owner-atom-syntax@mail.imc.org Mon Apr 25 11:40:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25862 for ; Mon, 25 Apr 2005 11:40:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PFQuco022428; Mon, 25 Apr 2005 08:26:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PFQud8022427; Mon, 25 Apr 2005 08:26:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PFQs0C022412 for ; Mon, 25 Apr 2005 08:26:54 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200504250654.DAD00305@ms8.netsolmail.com> References: <200504250654.DAD00305@ms8.netsolmail.com> Date: Mon, 25 Apr 2005 08:26:36 -0700 To: Atom WG From: Paul Hoffman Subject: RE: DSig (was: Comments on atompub-format-08 (Modified by Tim Bray)) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:54 AM -0400 4/25/05, Bob Wyman wrote: > One other *significant* limitation in Atom's support for signatures >is that there is no way for an intermediary to add to or otherwise modify an >Atom entry without breaking the signature. That's a purposeful design property of digital signatures. The exact same issue has long affected secure mail forwarders using S/MIME or OpenPGP. > What this means is that >intermediaries like PubSub, if they modify an entry by adding content, >repairing broken syntax, or normalizing character sets will be forced to >remove the original signature and insert a new signature issued by the >intermediary. Right. The intermediary can, however, add a signed extension that says "this message was earlier signed by Xyzzy, and we verified that signature before we changed things." If the recipient trusts your signature, they also must trust your attestation that you verified the earlier signature. > There are numerous other issues relating to signed Atom documents >that we've decided (somewhat unwisely...) to punt until after the core >document is released. The existing signature support is vitally important to >have in the core, however, I feel it really *must* be expanded upon >extensively in future extensions. Given that this is IETF Last Call, such issues are appropriate, and may delay us from getting a standard if the Security ADs bring them up. Can you list them? If they are Atom-specific, we can consider them; if they are generic to XMLDigSig, we probably have to punt (but will want to report them in the Security Considerations section of the draft). --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Apr 25 13:01:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01890 for ; Mon, 25 Apr 2005 13:01:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PGmo5I043291; Mon, 25 Apr 2005 09:48:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PGmoSc043290; Mon, 25 Apr 2005 09:48:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PGmniW043283 for ; Mon, 25 Apr 2005 09:48:50 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf7uk.cable.mindspring.com ([24.215.159.212] helo=[192.168.0.3]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DQ6lJ-0005G3-TW; Mon, 25 Apr 2005 16:48:46 +0000 Message-ID: <426D1F6E.60306@franklinmint.fm> Date: Mon, 25 Apr 2005 12:48:46 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax , iesg@ietf.org Subject: Last Call: required summary or content? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Greetings ATOMPUB and IESG, here is a last call issue, questioning the requirement for there to be a summary or content element in the Atom Format. Note that not all of the points are subjective musings on the nature of 'content' or 'consensus'. Some of them concern specifications which normatively reference the Atom Format, and one of them questions whether we've made proper use of one of our normative references. Process --------------------------------- It has been repeatedly suggested that it would be somehow inappropriate for me to raise this issue during last call. This is incorrect. "After it is submitted to the IESG, the IESG announces an IETF-wide last call. This helps get the attention of people who weren't following the progress of the draft, and can sometimes cause further changes to the draft. It is also a time when people in the WG who feel that they weren't heard can make their comments to everyone." -- http://www.ietf.org/tao.html Limiting Use --------------------------------- Atom protocol, del.icio.us, daypop, craigslist, and HTTPLR. Why do we wish to make these illegal under the Atom format? It servers no interop purpose. There is only advocacy along the lines of "users like feeds with content or summaries". Well, so what? Do daypop users like full content feeds? Do users on cellphones like them? Do apps have problems when feeds are not full content? The answer to all of these questions is no. Are they use cases that fall outside of our charter? No. We syndicate 'headlines'. RFC2119 --------------------------------- Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they *MUST only be used where it is actually required for interoperation* or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Atom Protocol --------------------------------- We have no idea how these requirements will effect the Atom Protocol, since we haven't settled on the meaning of empty vs. missing elements. * http://www.imc.org/atom-protocol/mail-archive/msg00756.html The cost of requiring summary or content is unknown, and therefore constitutes an unacceptable risk for the protocol. The Format/Protocol Overlap --------------------------------- http://www.mnot.net/blog/2005/04/12/feed_state Requirements in the Atom Format have made the protocol move to a separate syntax for "collections". If you read mnot's article above, you'll see that his problem overlaps a great deal with collection traversal in the protocol. By leveraging the same syntax for both problems, users can ease into the protocol by using simple things like mnot's proposed link relations. It would be simple to fit that into this protocol: http://www.ietf.org/internet-drafts/draft-sayre-atompub-protocol-basic-00.txt If we can't use the format for own protocol, what does that say about the level of reuse this restriction allows? Prior Art --------------------------------- RFC 2822: Optional body RSS 0.90: Required title, Required link, No description RSS 0.91: Required title, Required link, Optional description RSS 0.92: Optional title, Optional link, Optional description RSS 1.0: Required title, Required link, Optional description RSS 2.0: Optional title, Optional link, Optional description Atom 0.3: Required title, Required link, Optional summary and content Explicit Indication --------------------------------- http://www.imc.org/atom-syntax/mail-archive/msg06598.html From the Atom Protocol description of titles in POSTs: MUST be present. The element may be empty, to explicitly indicate "no title". Servers SHOULD NOT try to generate a title if one is not provided. The type attribute MAY be present, and if not it defaults to "text/plain". If present, it MUST represent a MIME type that the server supports. This makes sense. It does not, however, make sense for many metadata-only applications to explicitly indicate there is no summary or content. One example would be a titles-only listing of a large set of entries. Consensus, or not --------------------------------- * http://www.imc.org/atom-syntax/mail-archive/msg14154.html * http://www.imc.org/atom-syntax/mail-archive/msg14152.html * http://www.imc.org/atom-syntax/mail-archive/msg14162.html * http://www.imc.org/atom-syntax/mail-archive/msg10362.html * http://www.imc.org/atom-syntax/mail-archive/msg06601.html * http://www.imc.org/atom-syntax/mail-archive/msg13589.html * http://www.imc.org/atom-syntax/mail-archive/msg10387.html * http://www.imc.org/atom-syntax/mail-archive/msg10340.html * http://www.imc.org/atom-syntax/mail-archive/msg10310.html ...and the consensus call: * http://www.imc.org/atom-syntax/mail-archive/msg10338.html following that, the chairs got pushback on the summary requirement. I didn't see any text for or against the requirement previous to that. Then, accessibility arguments from Pilgrim and Isofarro, but do they still stand? I asked the chairs to have the current requirements reviewed by an accessibility expert. Besides, this is not the US Congress, where various riders slide through on the back of other legislation. Tying this requirement to the removal the abysmal content model that preceded it, and then insisting on 'consensus' around this requirement doesn't make much sense to me. Accessibility --------------------------------- No one is still making this argument, right? Robert Sayre From owner-atom-syntax@mail.imc.org Mon Apr 25 14:10:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07268 for ; Mon, 25 Apr 2005 14:10:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PI2fWj055851; Mon, 25 Apr 2005 11:02:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PI2fGM055850; Mon, 25 Apr 2005 11:02:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PI2clf055832 for ; Mon, 25 Apr 2005 11:02:39 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3PI1xWZ021373; Mon, 25 Apr 2005 19:02:05 +0100 (BST) In-Reply-To: <426D1F6E.60306@franklinmint.fm> References: <426D1F6E.60306@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8023d024697429b8d95118f9d4a8a5c8@mac.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: Last Call: required summary or content? Date: Mon, 25 Apr 2005 19:01:58 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Can you post some links to examples of feeds you think are difficult to express in the current syntax? That would be considerably more constructive than whatever the hell that was. Graham From owner-atom-syntax@mail.imc.org Mon Apr 25 14:17:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08285 for ; Mon, 25 Apr 2005 14:17:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PIAKxU056484; Mon, 25 Apr 2005 11:10:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PIAKeJ056483; Mon, 25 Apr 2005 11:10:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PIAJZZ056473 for ; Mon, 25 Apr 2005 11:10:19 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf7uk.cable.mindspring.com ([24.215.159.212] helo=[192.168.0.3]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DQ82B-0006d5-L6; Mon, 25 Apr 2005 18:10:15 +0000 Message-ID: <426D3288.2070507@franklinmint.fm> Date: Mon, 25 Apr 2005 14:10:16 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: atom-syntax Subject: Re: Last Call: required summary or content? References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> In-Reply-To: <8023d024697429b8d95118f9d4a8a5c8@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > Can you post some links to examples of feeds you think are difficult to > express in the current syntax? That would be considerably more > constructive than whatever the hell that was. I've done that before. Go read the archives. From owner-atom-syntax@mail.imc.org Mon Apr 25 14:31:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09298 for ; Mon, 25 Apr 2005 14:31:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PIP8Kx058259; Mon, 25 Apr 2005 11:25:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PIP86M058258; Mon, 25 Apr 2005 11:25:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PIP7uX058251 for ; Mon, 25 Apr 2005 11:25:07 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3PIP7i7017418 for ; Mon, 25 Apr 2005 12:25:07 -0600 (MDT) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IFI0064ALTUEX@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 25 Apr 2005 12:25:07 -0600 (MDT) Received: from [192.168.102.100] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFI000RQLTT8A@mail.sun.net> for atom-syntax@imc.org; Mon, 25 Apr 2005 12:25:06 -0600 (MDT) Date: Mon, 25 Apr 2005 11:25:57 -0700 From: Tim Bray Subject: PaceOptionalSummary In-reply-to: <8023d024697429b8d95118f9d4a8a5c8@mac.com> To: atom-syntax Syntax Message-id: <6d885e8145db474ec35d402a3b2d3b91@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 25, 2005, at 11:01 AM, Graham wrote: > Can you post some links to examples of feeds you think are difficult > to express in the current syntax? That would be considerably more > constructive than whatever the hell that was. What Rob wants is what he said in http://www.imc.org/atom-syntax/mail-archive/msg14157.html I decided it would help if there was an actual Pace: http://www.intertwingly.net/wiki/pie/PaceOptionalSummary From owner-atom-syntax@mail.imc.org Mon Apr 25 15:13:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13479 for ; Mon, 25 Apr 2005 15:13:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PJ2PoS063745; Mon, 25 Apr 2005 12:02:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PJ2Pl3063744; Mon, 25 Apr 2005 12:02:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3PJ2Ok6063733 for ; Mon, 25 Apr 2005 12:02:25 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 25 Apr 2005 19:02:17 -0000 Received: from p508FE981.dip.t-dialin.net (EHLO [192.168.0.3]) [80.143.233.129] by mail.gmx.net (mp020) with SMTP; 25 Apr 2005 21:02:17 +0200 X-Authenticated: #1915285 Message-ID: <426D3EB0.70704@gmx.de> Date: Mon, 25 Apr 2005 21:02:08 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: atom-syntax Syntax Subject: Re: PaceOptionalSummary References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> In-Reply-To: <6d885e8145db474ec35d402a3b2d3b91@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Apr 25, 2005, at 11:01 AM, Graham wrote: > >> Can you post some links to examples of feeds you think are difficult >> to express in the current syntax? That would be considerably more >> constructive than whatever the hell that was. > > > What Rob wants is what he said in > http://www.imc.org/atom-syntax/mail-archive/msg14157.html > > I decided it would help if there was an actual Pace: > http://www.intertwingly.net/wiki/pie/PaceOptionalSummary Thanks. Here's a meta comment, based on several years of real world implementation experience with the IETF WebDAV specs: It doesn't make sense to REQUIRE protocol elements for which there are valid reasonable use cases where implementations can't supply them and which aren't absolutely needed for interoperability. Also, if a protocol element is indeed not absolutely required, make sure that it's clear that leaving it out is *better* than supplying bad data. I'll supply two examples: #1: DAV:displayname property Many readers of RFC2518 came to the conclusion that a WebDAV resource MUST have a DAV:displayname property. Many implementations that aren't able to provide any additional metadata besides what they get from the file system thus use the filename (minus path) instead. This is not only a complete waste of bandwidth, but also causes lots of interop problems when resources like these are copied to other servers where DAV:displayname indeed works as designed (for instance, renaming the resource will not cause DAV:displayname to change anymore like it did on the origin server). #2: DAV:getcontentlanguage property (same for HTTP "Content-Language" header) I've seen servers providing the server installation's locale name as a default. I've seen clients (MS Webfolder) that send a Content-Language header hardwired to "en-us" for any document they HTTP PUT. In both cases, recipients receive bad metadata, instead of no data at all which would be preferrable. In both cases, there'd be fewer interop problems (and incorrect metadata) if the specs would allow not to send these protocol elements (and be clear about that you shouldn't make them up if you don't have them). Please consider this when discussing this Pace and the link/alternate issue as well. Best regards, Julian From owner-atom-syntax@mail.imc.org Mon Apr 25 16:36:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22038 for ; Mon, 25 Apr 2005 16:36:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PKPo9d078348; Mon, 25 Apr 2005 13:25:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PKPobG078347; Mon, 25 Apr 2005 13:25:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PKPnPv078332 for ; Mon, 25 Apr 2005 13:25:49 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3PKOkvJ004353; Mon, 25 Apr 2005 21:24:55 +0100 (BST) In-Reply-To: <6d885e8145db474ec35d402a3b2d3b91@sun.com> References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <432320f71c935c389e73f1808675db18@mac.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: PaceOptionalSummary Date: Mon, 25 Apr 2005 21:24:47 +0100 To: Tim Bray X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I would much prefer changing the MUST to a SHOULD rather than dropping the requirement completely, which would achieve the same goal. I don't believe requiring at least a summary is an unfair baseline requirement in other use cases. (btw I also think there's an equally valid use-case for body-only feeds) Graham On 25 Apr 2005, at 7:25 pm, Tim Bray wrote: >> re constructive than whatever the hell that was. > > What Rob wants is what he said in > http://www.imc.org/atom-syntax/mail-archive/msg14157.html > > I decided it would help if there was an actual Pace: > http://www.intertwingly.net/wiki/pie/PaceOptionalSummary > From owner-atom-syntax@mail.imc.org Mon Apr 25 16:50:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26927 for ; Mon, 25 Apr 2005 16:50:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PKYCfG080169; Mon, 25 Apr 2005 13:34:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PKYCnJ080167; Mon, 25 Apr 2005 13:34:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PKYBQJ080160 for ; Mon, 25 Apr 2005 13:34:11 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 20134E0063; Mon, 25 Apr 2005 16:34:07 -0400 (EDT) To: Robert Sayre Cc: Atom-Syntax , iesg@ietf.org Subject: Re: Last Call: required summary or content? References: <426D1F6E.60306@franklinmint.fm> From: Sam Hartman Date: Mon, 25 Apr 2005 16:34:07 -0400 In-Reply-To: <426D1F6E.60306@franklinmint.fm> (Robert Sayre's message of "Mon, 25 Apr 2005 12:48:46 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi. Speaking as an IESG member with limited context on the issue you raise, you did not provide enough detail for me to understand the point you bring up. I think the focus of your message was wrong. You spent a lot of space talking about IETF process and about how this would effect various uses of atom. Your understanding of the process does seem correct, but it seems like it is the wrong focus for the argument you are trying to make. Rather than explaining why it is appropriate for you to make your argument please get around to making the argument whatever it is. In particular, focus on the following: * What the specification does currently * What you would like it to do instead * why you believe this is the right choice In addition it would be helpful if you would explain other positions to the best of your ability. In all likelihood advocates of those positions will fill us in in great detail, but it can't hurt for you to povide your understanding of the complete thinking on the issue. From owner-atom-syntax@mail.imc.org Mon Apr 25 16:51:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27368 for ; Mon, 25 Apr 2005 16:51:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PKX8Tm079944; Mon, 25 Apr 2005 13:33:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PKX8nd079943; Mon, 25 Apr 2005 13:33:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PKX81S079937 for ; Mon, 25 Apr 2005 13:33:08 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3PKaquk003843; Mon, 25 Apr 2005 16:36:59 -0400 Message-ID: <426D53F6.805@intertwingly.net> Date: Mon, 25 Apr 2005 16:32:54 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: atom-syntax Syntax Subject: Re: PaceOptionalSummary References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> In-Reply-To: <6d885e8145db474ec35d402a3b2d3b91@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Apr 25, 2005, at 11:01 AM, Graham wrote: > >> Can you post some links to examples of feeds you think are difficult >> to express in the current syntax? That would be considerably more >> constructive than whatever the hell that was. > > What Rob wants is what he said in > http://www.imc.org/atom-syntax/mail-archive/msg14157.html > > I decided it would help if there was an actual Pace: > http://www.intertwingly.net/wiki/pie/PaceOptionalSummary -1 Steamroll over me and others if you must, but I believe that title only feeds are more often that way due to an error of omission than by an explicit design choice. Enough so that it warrants someone explicitly saying "this summarly intentionally left blank", thus: Given a way to express an intentional omission of a summary, this discussion changes from a discussion of use cases that allegedly are not supported, to one of whether tools like RNG grammars and feedvalidators can assist people who produce feeds in making their intents clear. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Apr 25 16:55:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28340 for ; Mon, 25 Apr 2005 16:55:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PKkZQg082821; Mon, 25 Apr 2005 13:46:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PKkZgV082820; Mon, 25 Apr 2005 13:46:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PKkYp6082797 for ; Mon, 25 Apr 2005 13:46:34 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2435261wra for ; Mon, 25 Apr 2005 13:46:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Cy7WVf6yKCveZA4kj2A7o5Qsk/CDYdmFF6/JAMMNFLtRZcigncyqa4lHYp+pVXfLamptiWf7VZbJ+UTV1Rz6qYIvknS2HHFb28CE5KeeHezz+kJC38Tv7AzHJBOVey1P+XAiTy35I5HdcMwsoRsvhXFidQtu7Fsu4NtZw/qjkZE= Received: by 10.54.78.16 with SMTP id a16mr232333wrb; Mon, 25 Apr 2005 13:46:28 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Mon, 25 Apr 2005 13:46:28 -0700 (PDT) Message-ID: <68fba5c505042513462f2703b6@mail.gmail.com> Date: Mon, 25 Apr 2005 16:46:28 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceOptionalSummary Cc: Tim Bray , atom-syntax In-Reply-To: <432320f71c935c389e73f1808675db18@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <432320f71c935c389e73f1808675db18@mac.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3PKkYp6082812 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/25/05, Graham wrote: > > I would much prefer changing the MUST to a SHOULD rather than dropping > the requirement completely, which would achieve the same goal. Incorrect. There are no interoperability issues with title-only feeds. There may be users unhappy with the content in some cases, but that's not a technical issue. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Apr 25 18:26:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06198 for ; Mon, 25 Apr 2005 18:26:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PMEaLW095625; Mon, 25 Apr 2005 15:14:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PMEaOm095624; Mon, 25 Apr 2005 15:14:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PMEXVl095614 for ; Mon, 25 Apr 2005 15:14:35 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf7uk.cable.mindspring.com ([24.215.159.212] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DQBqW-0003YZ-N2; Mon, 25 Apr 2005 22:14:28 +0000 Message-ID: <426D6BC6.3020805@franklinmint.fm> Date: Mon, 25 Apr 2005 18:14:30 -0400 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: Atom-Syntax , iesg@ietf.org Subject: Re: Last Call: required summary or content? References: <426D1F6E.60306@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Hartman wrote: > Hi. Speaking as an IESG member with limited context on the issue you > raise, you did not provide enough detail for me to understand the > point you bring up. Hi Sam. I apologize for that. I see now that I was too brief on the technical point, and too long winded for the IESG. The process stuff was for the benefit of the WG, most of whom (including me) are new to the IETF. > Your understanding of the process does seem correct, but it seems like > it is the wrong focus for the argument you are trying to make. Perhaps I misunderstood the process a bit, in that I thought I had to send my message to the IESG as part of the process. I consider it quite likely that the WG will resolve this issue itself, but I wanted to make sure it was not stuffed by process arguments. > > * What the specification does currently In an Atom Entry, the specification currently requires a minimum set of elements: , <id>, and <updated>. Typically, there will also be a <link> element. The specification includes a provision that allows its omission on the condition that there is a <content> element. In addition to that, the specification requires that either <summary> or <content> be present. > * What you would like it to do instead I want to allow the metadata-only feeds allowed by all flavors of RSS, and the omission of the <content> and <summary>. Such feeds are commonly termed "title-only feeds", because that is all that is visible to the user (the title is usually hyperlinked w/ the link element). > * why you believe this is the right choice I believe this is the right choice because title-only feeds are not a significant source of interoperability problems in current formats. It can often be a source a unhappy users, but that is not a specification problem. There are services taking this approach that are successful. In addition, the WG has not decided on the significance of absent or empty summary/content in the Atom Protocol. > > In addition it would be helpful if you would explain other positions > to the best of your ability. In all likelihood advocates of those > positions will fill us in in great detail, but it can't hurt for you > to povide your understanding of the complete thinking on the issue. The other position seems to be that title-only feeds are usually the result of an error made by a producer who doesn't understand syndication users' expectations very well. I fully agree that's a common occurrence, but it results in unhappy users who complain to the publisher, not broken or buggy clients. On the other end of the spectrum, advanced, site-to-site, or bandwidth-constrained users frequently produce title-only feeds. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Apr 25 18:39:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07189 for <atompub-archive@lists.ietf.org>; Mon, 25 Apr 2005 18:39:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PMMnXw096895; Mon, 25 Apr 2005 15:22:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PMMnDd096894; Mon, 25 Apr 2005 15:22:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PMMmlL096874 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 15:22:48 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2484914wra for <atom-syntax@imc.org>; Mon, 25 Apr 2005 15:22:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C5TvamA2uvrnhYzJC1HeiTJ3s+RJi2QDFSgchfIY9Gx4FMBvNpnhJMd+aONncaDEUtFSyespUyxM10m9RbbUO/mJm7EDFnwr4NXVkcHuFSMm2rLdXXubGm6WKkTR+q4Qkot2/Cqbk62EUTS98BJndfg74ziUBD9ifMgkE3ph3RQ= Received: by 10.54.115.13 with SMTP id n13mr2219392wrc; Mon, 25 Apr 2005 15:22:40 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Mon, 25 Apr 2005 15:22:40 -0700 (PDT) Message-ID: <68fba5c505042515227eb0d195@mail.gmail.com> Date: Mon, 25 Apr 2005 18:22:40 -0400 From: Robert Sayre <sayrer@gmail.com> Reply-To: Robert Sayre <sayrer@gmail.com> To: Julian Reschke <julian.reschke@gmx.de> Subject: Re: PaceOptionalSummary Cc: Tim Bray <Tim.Bray@Sun.COM>, atom-syntax Syntax <atom-syntax@imc.org> In-Reply-To: <426D3EB0.70704@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <426D3EB0.70704@gmx.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3PMMmlL096888 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On 4/25/05, Julian Reschke <julian.reschke@gmx.de> wrote: > > Tim Bray wrote: > > > > I decided it would help if there was an actual Pace: > > http://www.intertwingly.net/wiki/pie/PaceOptionalSummary > It doesn't make sense to REQUIRE protocol elements for which there are > valid reasonable use cases where implementations can't supply them and > which aren't absolutely needed for interoperability. This Pace addresses my concerns in full. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Apr 25 18:57:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08961 for <atompub-archive@lists.ietf.org>; Mon, 25 Apr 2005 18:57:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PMnHgZ000625; Mon, 25 Apr 2005 15:49:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3PMnHlW000624; Mon, 25 Apr 2005 15:49:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ussjmh01.bea.com (ussjmh01.bea.com [63.96.162.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3PMnH25000618 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 15:49:17 -0700 (PDT) (envelope-from markn@bea.com) Received: from ussjfe02.amer.bea.com (ussjfe02.bea.com [172.16.120.52]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id j3PMnG4w003536 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 15:49:16 -0700 Received: from USSFEX01.amer.bea.com ([10.32.0.56]) by ussjfe02.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Apr 2005 15:49:16 -0700 Received: from [172.16.1.5] ([172.24.28.90]) by USSFEX01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Apr 2005 15:49:15 -0700 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <c891d69c89e6d3128d131e7b658611a9@bea.com> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham <mark.nottingham@bea.com> X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})<LET/,:$!V Z2a`,}:,!$ZW-^s0JO}F[(71D38:rzvK|7DB;VA|@`]uggG,{@2UuA$XpM;r|[[w/bQ&P4 zW"FB+p{u)CCjiRx=c)-S=c>B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Fwd: For review: application/atom+xml Date: Mon, 25 Apr 2005 15:49:12 -0700 To: Atom Syntax <atom-syntax@imc.org> X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 25 Apr 2005 22:49:15.0890 (UTC) FILETIME=[01F3F520:01C549E9] X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.4.25.9 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Comments on the media type template. Begin forwarded message: > From: Mark Baker <distobj@acm.org> > Date: April 20, 2005 11:13:54 AM PDT > To: ietf-types@alvestrand.no > Cc: iesg@ietf.org > Subject: Re: For review: application/atom+xml > > [ CC: IESG, since I suppose this counts as a last call comment ] > > Mark, > > Congrats on going to last call with the atompub format! - > > http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt > > But I note that my comment[1] on the lack of any mention of the > existing > use of application/atom+xml with the incompatible Atom 0.3 content > didn't make it in. Though not widespread, my understanding (though I'd > be happy to be corrected!), at least at the time that you first drew up > this media type[2], was that it was in use[3]. I certainly don't feel > that this is a big enough problem to warrant a new media type, but I do > think it should be flagged to implementors. > > Also, I noticed something else that I missed my first time through ... > > On Wed, Apr 06, 2005 at 08:41:08PM -0700, Mark Nottingham wrote: >> Additional information: >> >> Magic number(s): As specified for "application/xml" in [RFC3023], >> section 3.2. > > Based on my understanding of the purpose of magic numbers, I think > referencing another spec's magic number algorithm to be prima facie > incorrect. What I think should be there is information that, as > uniquely as possible, identifies Atom documents, and RFC 3023 can, of > course, only help with identifying XML documents. So I'd suggest > either > adding something about the root namespace value (if indeed the spec > requires that the root element always be from the Atom namespace?) as I > did for XHTML[4], or else just saying "Magic Number: None" (as we did > for SOAP[5], in effect, by not providing an algorithm). > > Cheers, > > [1] > http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/ > 000678.html > [2] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html > [3] http://diveintomark.org/archives/2003/12/13/atom03 > [4] http://www.ietf.org/rfc/rfc3236.txt > [5] http://www.ietf.org/rfc/rfc3902.txt > > Mark. > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > > -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems From owner-atom-syntax@mail.imc.org Mon Apr 25 20:16:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14208 for <atompub-archive@lists.ietf.org>; Mon, 25 Apr 2005 20:16:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q05xik012808; Mon, 25 Apr 2005 17:05:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3Q05xRB012807; Mon, 25 Apr 2005 17:05:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q05vB1012798 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 17:05:58 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3Q09bTl028740; Mon, 25 Apr 2005 20:09:40 -0400 Message-ID: <426D85D1.7060602@intertwingly.net> Date: Mon, 25 Apr 2005 20:05:37 -0400 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre <mint@franklinmint.fm> CC: Sam Hartman <hartmans-ietf@mit.edu>, Atom-Syntax <atom-syntax@imc.org>, iesg@ietf.org Subject: Re: Last Call: required summary or content? References: <426D1F6E.60306@franklinmint.fm> <tslekcyvbnk.fsf@cz.mit.edu> <426D6BC6.3020805@franklinmint.fm> In-Reply-To: <426D6BC6.3020805@franklinmint.fm> 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: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Robert Sayre wrote: > >> * What the specification does currently > > In an Atom Entry, the specification currently requires a minimum set of > elements: <title>, <id>, and <updated>. Typically, there will also be a > <link> element. The specification includes a provision that allows its > omission on the condition that there is a <content> element. In addition > to that, the specification requires that either <summary> or <content> > be present. > >> * What you would like it to do instead > > I want to allow the metadata-only feeds allowed by all flavors of RSS, > and the omission of the <content> and <summary>. Such feeds are commonly > termed "title-only feeds", because that is all that is visible to the > user (the title is usually hyperlinked w/ the link element). I will again point out that the current format allows for empty summary and/or content elements. I have seen errors that the requirement for the inclusion of such elements would have prevented. I have seen no arguments as to why placing such empty elements would impose an unreasonable burden on implementers. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Apr 25 20:20:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14678 for <atompub-archive@lists.ietf.org>; Mon, 25 Apr 2005 20:20:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q09hQi013324; Mon, 25 Apr 2005 17:09:43 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3Q09hSP013323; Mon, 25 Apr 2005 17:09:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q09g46013317 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 17:09:42 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3Q09gi7014956 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 18:09:42 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IFJ00KFY1S56V@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 25 Apr 2005 18:09:42 -0600 (MDT) Received: from [10.255.255.107] ([207.81.152.47]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFJ00ADV1S4OI@mail.sun.net> for atom-syntax@imc.org; Mon, 25 Apr 2005 18:09:41 -0600 (MDT) Date: Mon, 25 Apr 2005 17:10:33 -0700 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: For review: application/atom+xml In-reply-to: <c891d69c89e6d3128d131e7b658611a9@bea.com> To: Mark Nottingham <mark.nottingham@bea.com> Cc: Atom Syntax <atom-syntax@imc.org> Message-id: <cd1eab4a4e8c22579c60f8005edbbe9a@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <c891d69c89e6d3128d131e7b658611a9@bea.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT On Apr 25, 2005, at 3:49 PM, Mark Nottingham wrote: > > Comments on the media type template. He's got a point on the namespace being mentioned, which creates some semi-circular dependencies, sigh. As to whether it's currently in use, largely due to lobbying from us, recent releases of both Apache and IIS tie the application/atom+xml media type to the .atom extension, so if people are creating 0.3 files and calling them whatever.atom, this could be right. Having said that, I think we should push back. Because any such current usage is unlicensed by any spec, & because we plan to aggressively deprecate Atom 0.3 once we get 1.0 out and since I suspect that 90% of 0.3 feeds come from one place we should have some success. -Tim > > Begin forwarded message: > >> From: Mark Baker <distobj@acm.org> >> Date: April 20, 2005 11:13:54 AM PDT >> To: ietf-types@alvestrand.no >> Cc: iesg@ietf.org >> Subject: Re: For review: application/atom+xml >> >> [ CC: IESG, since I suppose this counts as a last call comment ] >> >> Mark, >> >> Congrats on going to last call with the atompub format! - >> >> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt >> >> But I note that my comment[1] on the lack of any mention of the >> existing >> use of application/atom+xml with the incompatible Atom 0.3 content >> didn't make it in. Though not widespread, my understanding (though >> I'd >> be happy to be corrected!), at least at the time that you first drew >> up >> this media type[2], was that it was in use[3]. I certainly don't feel >> that this is a big enough problem to warrant a new media type, but I >> do >> think it should be flagged to implementors. >> >> Also, I noticed something else that I missed my first time through ... >> >> On Wed, Apr 06, 2005 at 08:41:08PM -0700, Mark Nottingham wrote: >>> Additional information: >>> >>> Magic number(s): As specified for "application/xml" in [RFC3023], >>> section 3.2. >> >> Based on my understanding of the purpose of magic numbers, I think >> referencing another spec's magic number algorithm to be prima facie >> incorrect. What I think should be there is information that, as >> uniquely as possible, identifies Atom documents, and RFC 3023 can, of >> course, only help with identifying XML documents. So I'd suggest >> either >> adding something about the root namespace value (if indeed the spec >> requires that the root element always be from the Atom namespace?) as >> I >> did for XHTML[4], or else just saying "Magic Number: None" (as we did >> for SOAP[5], in effect, by not providing an algorithm). >> >> Cheers, >> >> [1] >> http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/ >> 000678.html >> [2] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html >> [3] http://diveintomark.org/archives/2003/12/13/atom03 >> [4] http://www.ietf.org/rfc/rfc3236.txt >> [5] http://www.ietf.org/rfc/rfc3902.txt >> >> Mark. >> -- >> Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca >> >> > > -- > Mark Nottingham Principal Technologist > Office of the CTO BEA Systems > > - Tim Bray, Director of Web Technologies, Sun Microsystems +1-877-305-0889 Sun ext. 60561 http://www.tbray.org/ongoing/ AIM: MarkupPedant From owner-atom-syntax@mail.imc.org Mon Apr 25 20:25:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14908 for <atompub-archive@lists.ietf.org>; Mon, 25 Apr 2005 20:25:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q0HGGc014535; Mon, 25 Apr 2005 17:17:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3Q0HGmU014534; Mon, 25 Apr 2005 17:17:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q0HF6c014525 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 17:17:15 -0700 (PDT) (envelope-from mint@franklinmint.fm) Received: from user-0cdf7uk.cable.mindspring.com ([24.215.159.212] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1DQDlG-0006WT-P4; Tue, 26 Apr 2005 00:17:10 +0000 Message-ID: <426D8888.6010005@franklinmint.fm> Date: Mon, 25 Apr 2005 20:17:12 -0400 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby <rubys@intertwingly.net> CC: Atom-Syntax <atom-syntax@imc.org> Subject: Re: Last Call: required summary or content? References: <426D1F6E.60306@franklinmint.fm> <tslekcyvbnk.fsf@cz.mit.edu> <426D6BC6.3020805@franklinmint.fm> <426D85D1.7060602@intertwingly.net> In-Reply-To: <426D85D1.7060602@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit [snipped IESG] Sam Ruby wrote: > I will again point out that the current format allows for empty summary > and/or content elements. Sure, but it doesn't define them. > I have seen errors that the requirement for the inclusion of such > elements would have prevented. Please define the term error more precisely. > I have seen no arguments as to why placing such empty elements would > impose an unreasonable burden on implementers. Please outline the effects of this requirement on the protocol, because I have no idea what they might be. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Apr 25 21:28:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18775 for <atompub-archive@lists.ietf.org>; Mon, 25 Apr 2005 21:28:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q1Ha9G024950; Mon, 25 Apr 2005 18:17:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3Q1HavU024949; Mon, 25 Apr 2005 18:17:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q1HYO2024931 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 18:17:35 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 26 Apr 2005 08:17:38 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 26 Apr 2005 11:17:28 +1000 Subject: Re: PaceOptionalSummary From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE93D3C8.56488%eric.scheid@ironclad.net.au> In-Reply-To: <6d885e8145db474ec35d402a3b2d3b91@sun.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 26/4/05 4:25 AM, "Tim Bray" <Tim.Bray@Sun.COM> wrote: > I decided it would help if there was an actual Pace: > http://www.intertwingly.net/wiki/pie/PaceOptionalSummary +1 From owner-atom-syntax@mail.imc.org Mon Apr 25 22:28:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23304 for <atompub-archive@lists.ietf.org>; Mon, 25 Apr 2005 22:28:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q2KgZa036440; Mon, 25 Apr 2005 19:20:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3Q2KgWE036439; Mon, 25 Apr 2005 19:20:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q2KfVF036384 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 19:20:42 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc13) with SMTP id <20050426022026015004vntle>; Tue, 26 Apr 2005 02:20:26 +0000 Date: Mon, 25 Apr 2005 20:20:23 -0600 Subject: Re: PaceOptionalSummary Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <6d885e8145db474ec35d402a3b2d3b91@sun.com> Message-Id: <BEEF5309-B5F9-11D9-A0FD-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Monday, April 25, 2005, at 12:25 PM, Tim Bray wrote: > I decided it would help if there was an actual Pace: > http://www.intertwingly.net/wiki/pie/PaceOptionalSummary > +1 From owner-atom-syntax@mail.imc.org Mon Apr 25 22:39:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24621 for <atompub-archive@lists.ietf.org>; Mon, 25 Apr 2005 22:39:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q2W3KO038427; Mon, 25 Apr 2005 19:32:03 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3Q2W3WQ038426; Mon, 25 Apr 2005 19:32:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q2W32V038419 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 19:32:03 -0700 (PDT) (envelope-from jtauber@jtauber.com) Received: from web2.messagingengine.com (web2.internal [10.202.2.211]) by frontend1.messagingengine.com (Postfix) with ESMTP id 3B2BCC78821 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 22:32:01 -0400 (EDT) Received: by web2.messagingengine.com (Postfix, from userid 99) id 7C3DE2B1F; Mon, 25 Apr 2005 22:31:50 -0400 (EDT) Message-Id: <1114482710.528.232706828@webmail.messagingengine.com> X-Sasl-Enc: +d92h/yvHir/ZufrZe8WjiHWJYzpe3o++r0PewxOAIk4 1114482710 From: "James Tauber" <jtauber@jtauber.com> To: "atom-syntax Syntax" <atom-syntax@imc.org> Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.001; A1.64; B3.05; Q3.03) References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> Subject: Re: PaceOptionalSummary In-Reply-To: <6d885e8145db474ec35d402a3b2d3b91@sun.com> Date: Tue, 26 Apr 2005 10:31:50 +0800 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Mon, 25 Apr 2005 11:25:57 -0700, "Tim Bray" <Tim.Bray@Sun.COM> said: > I decided it would help if there was an actual Pace: > http://www.intertwingly.net/wiki/pie/PaceOptionalSummary +1 James -- James Tauber http://jtauber.com/ journeyman of some http://jtauber.com/blog/ From owner-atom-syntax@mail.imc.org Mon Apr 25 23:45:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29665 for <atompub-archive@lists.ietf.org>; Mon, 25 Apr 2005 23:45:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q3b1kq046761; Mon, 25 Apr 2005 20:37:01 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3Q3b1NP046760; Mon, 25 Apr 2005 20:37:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q3awZh046724 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 20:36:59 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j3Q3ap702053; Tue, 26 Apr 2005 12:36:51 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id a64f0bb8_b605_11d9_8f04_0030482532aa_21860; Tue, 26 Apr 2005 12:45:36 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO003FFC; 26 Apr 05 12:38:42 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 26 Apr 05 12:38:14 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.52) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG003FF7; 26 Apr 05 12:38:10 +0900 Message-Id: <6.0.0.20.2.20050426103838.04c3c090@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 26 Apr 2005 10:38:42 +0900 To: Eric Scheid <eric.scheid@ironclad.net.au>, Atom Syntax <atom-syntax@imc.org> From: Martin Duerst <duerst@it.aoyama.ac.jp> Subject: Re: PaceOptionalSummary In-Reply-To: <BE93D3C8.56488%eric.scheid@ironclad.net.au> References: <6d885e8145db474ec35d402a3b2d3b91@sun.com> <BE93D3C8.56488%eric.scheid@ironclad.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit +1 At 10:17 05/04/26, Eric Scheid wrote: > >On 26/4/05 4:25 AM, "Tim Bray" <Tim.Bray@Sun.COM> wrote: > >> I decided it would help if there was an actual Pace: >> http://www.intertwingly.net/wiki/pie/PaceOptionalSummary > >+1 From owner-atom-syntax@mail.imc.org Tue Apr 26 01:32:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09497 for <atompub-archive@lists.ietf.org>; Tue, 26 Apr 2005 01:32:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q5MSvl071919; Mon, 25 Apr 2005 22:22:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3Q5MSSf071918; Mon, 25 Apr 2005 22:22:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q5MS0F071905 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 22:22:28 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3Q5MRjO029912 for <atom-syntax@imc.org>; Mon, 25 Apr 2005 23:22:27 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IFJ0064MG9EEX@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Mon, 25 Apr 2005 23:22:27 -0600 (MDT) Received: from [10.12.0.250] ([65.89.25.214]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFJ00AEVG9BOI@mail.sun.net> for atom-syntax@imc.org; Mon, 25 Apr 2005 23:22:23 -0600 (MDT) Date: Mon, 25 Apr 2005 22:23:15 -0700 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: PaceOptionalSummary In-reply-to: <6d885e8145db474ec35d402a3b2d3b91@sun.com> To: Tim Bray <Tim.Bray@Sun.COM> Cc: atom-syntax Syntax <atom-syntax@imc.org> Message-id: <672bc8dc873220a2070555424e9f7e4d@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT I was driving to the airport with Lauren, whom some of you will know, she's technical but hasn't been following Atom. I explained the debate we are having over the required-ness of <atom:summary>, and she said "Don't you have anything better to talk about?" I suspect she has a point. Suppose we leave it the way it is... people who don't want to include a summary can use <summary/>, so it's just silly to say that there's an example of a current feed that would be ruled out. For that matter, Graham's body-only feeds can be done with <title/>. I can see Sam's arguments, but on the other hand, the errors that might get caught by requiring summary are probably boring corner-cases anyhow. Which is to say, it doesn't matter very much. Which is to say, Paul & I are gonna watch a little more debate and then we'll call rough consensus one way or the other, at which point I at least will become crushingly rude to anyone who wants to invest more time in this. -Tim From owner-atom-syntax@mail.imc.org Tue Apr 26 03:24:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09198 for <atompub-archive@lists.ietf.org>; Tue, 26 Apr 2005 03:24:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q7F4pS025747; Tue, 26 Apr 2005 00:15:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3Q7F4Qj025746; Tue, 26 Apr 2005 00:15:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3Q7F10Q025689 for <atom-syntax@imc.org>; Tue, 26 Apr 2005 00:15:02 -0700 (PDT) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 26 Apr 2005 07:14:55 -0000 Received: from p508FE981.dip.t-dialin.net (EHLO [192.168.0.3]) [80.143.233.129] by mail.gmx.net (mp002) with SMTP; 26 Apr 2005 09:14:55 +0200 X-Authenticated: #1915285 Message-ID: <426DEA6A.6010602@gmx.de> Date: Tue, 26 Apr 2005 09:14:50 +0200 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby <rubys@intertwingly.net> CC: Robert Sayre <mint@franklinmint.fm>, Sam Hartman <hartmans-ietf@mit.edu>, Atom-Syntax <atom-syntax@imc.org>, iesg@ietf.org Subject: Re: Last Call: required summary or content? References: <426D1F6E.60306@franklinmint.fm> <tslekcyvbnk.fsf@cz.mit.edu> <426D6BC6.3020805@franklinmint.fm> <426D85D1.7060602@intertwingly.net> In-Reply-To: <426D85D1.7060602@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Sam Ruby wrote: > ... > I will again point out that the current format allows for empty summary > and/or content elements. > > I have seen errors that the requirement for the inclusion of such > elements would have prevented. > > I have seen no arguments as to why placing such empty elements would > impose an unreasonable burden on implementers. > ... Again speaking based on experience using XML formatted protocol data: As far as I can tell, using empty elements to signal the *absence* of information is a potential source of interoperability problems. For instance, clients may behave differently based on whether some piece of data exists, but fail to handle an empty string value as "no" value. So, at a minimum, the spec would need to be clear about the fact that if something has no text content, it means "this information is missing" instead of "this information is present and has an empty string value". Also keep in mind that people *will* break rules as long at it simplifies their own work and they get away with it. It'll be hard to explain why it's necessary to marshall an element with no text content, if clients will treat the absence of this element the same way (and they will). If both notations carry the same semantics, and both are likely to be used no matter what the RFC says, it IMHO would be wise to allow both. Best regards, Julian From owner-atom-syntax@mail.imc.org Tue Apr 26 04:45:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14781 for <atompub-archive@lists.ietf.org>; Tue, 26 Apr 2005 04:45:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3Q8axcP055678; Tue, 26 Apr 2005 01:36:59 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3Q8axdf055677; Tue, 26 Apr 2005 01:36:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3Q8avTb055638 for <atom-syntax@imc.org>; Tue, 26 Apr 2005 01:36:58 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 37145 messnum 5763820 invoked from network[83.70.217.193/unknown]); 26 Apr 2005 08:36:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail12.svc.cra.dublin.eircom.net (qp 37145) with SMTP; 26 Apr 2005 08:36:51 -0000 Message-ID: <426DFD9F.1080707@dehora.net> Date: Tue, 26 Apr 2005 09:36:47 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Syntax <atom-syntax@imc.org> CC: iesg@ietf.org Subject: Re: PaceOptionalSummary References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> In-Reply-To: <6d885e8145db474ec35d402a3b2d3b91@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Tim Bray wrote: > http://www.intertwingly.net/wiki/pie/PaceOptionalSummary 0 As editor of the one the protocols cited in favour (HTTPLR) I'd like to clarify this position, especially as the debate around this issue has imo been emotionally charged; most recently there's been talk of inappropriateness and steamrolling. That encourages me to stay neutral. The absence or otherwise of atom:summary causes no interoperability problems for that protocol; HTTPLR agents are not licensed to process summaries. The use of Atom in HTTPLR is arguably not a common usecase (today at least). Of the people I know implementing it, atom:summary has not come up as an issue. It appears to make no odds one way or another if atom:summary there or not empty or not. Finally please note that HTTPLR is different from the other cases cited which might or might not be relevant to the IESG and ATOMPUB. First, it's a protocol, not a website. Second, it's not gone through the IETF process a la APP, though it will appear as an I-D around June of this year. cheers Bill From owner-atom-syntax@mail.imc.org Tue Apr 26 07:23:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27527 for <atompub-archive@lists.ietf.org>; Tue, 26 Apr 2005 07:23:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QBEgmH027056; Tue, 26 Apr 2005 04:14:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QBEgjE027055; Tue, 26 Apr 2005 04:14:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QBEf5O027003 for <atom-syntax@imc.org>; Tue, 26 Apr 2005 04:14:42 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2782659wra for <atom-syntax@imc.org>; Tue, 26 Apr 2005 04:14:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oUkH7BJRkxOLw3XvEgMdsl9gDsL6vFC+SMOcoZ9DoEVOIJprDX/jGMAusnhprwupGuC0tG4AVIZqCy4zP14Zt5MbcL6TEgzK/JKqjXqLP1jLrspRhpJkX+w7p1J7+o1mQuQVwJUhT5tvo4CXH9vR9Y3LvYoSCS9PddtOjCeX+4c= Received: by 10.54.33.39 with SMTP id g39mr419310wrg; Tue, 26 Apr 2005 04:14:36 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 26 Apr 2005 04:14:35 -0700 (PDT) Message-ID: <68fba5c505042604143f4e8e82@mail.gmail.com> Date: Tue, 26 Apr 2005 07:14:35 -0400 From: Robert Sayre <sayrer@gmail.com> Reply-To: Robert Sayre <sayrer@gmail.com> To: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: PaceOptionalSummary Cc: atom-syntax Syntax <atom-syntax@imc.org> In-Reply-To: <672bc8dc873220a2070555424e9f7e4d@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <672bc8dc873220a2070555424e9f7e4d@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3QBEg5O027048 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On 4/26/05, Tim Bray <Tim.Bray@sun.com> wrote: > she said > "Don't you have anything better to talk about?" I suspect she has a > point. Welcome to atom-syntax. :) > Suppose we leave it the way it is... people who don't want to > include a summary can use <summary/>, so it's just silly to say that > there's an example of a current feed that would be ruled out. Consider a message from client to server using the Atom Protocol. Do the following messages mean the same thing? <entry>... <id>...</id> <title>... ... ... ... ... ... ... I have my thoughts, but the WG hasn't decided. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 26 09:35:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08160 for ; Tue, 26 Apr 2005 09:35:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QDJFif075659; Tue, 26 Apr 2005 06:19:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QDJFYo075658; Tue, 26 Apr 2005 06:19:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QDJE1e075652 for ; Tue, 26 Apr 2005 06:19:14 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3QDN9ut005902; Tue, 26 Apr 2005 09:23:10 -0400 Message-ID: <426E3FC7.3080801@intertwingly.net> Date: Tue, 26 Apr 2005 09:19:03 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: atom-syntax Syntax Subject: Re: PaceOptionalSummary References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <672bc8dc873220a2070555424e9f7e4d@sun.com> In-Reply-To: <672bc8dc873220a2070555424e9f7e4d@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > I was driving to the airport with Lauren, whom some of you will know, > she's technical but hasn't been following Atom. I explained the debate > we are having over the required-ness of , and she said > "Don't you have anything better to talk about?" I suspect she has a > point. Suppose we leave it the way it is... people who don't want to > include a summary can use , so it's just silly to say that > there's an example of a current feed that would be ruled out. For that > matter, Graham's body-only feeds can be done with . I can see > Sam's arguments, but on the other hand, the errors that might get caught > by requiring summary are probably boring corner-cases anyhow. > > Which is to say, it doesn't matter very much. > > Which is to say, Paul & I are gonna watch a little more debate and then > we'll call rough consensus one way or the other, at which point I at > least will become crushingly rude to anyone who wants to invest more > time in this. -Tim The feedvalidator catches silly, boring corner-cases every day. I hesitate to bring it up again as it has proven to incite adhominen attacks from within this workgroup, but we have an example of a respected journalist who has published a book in which he specifically called out this. And we have the experience from RSS 2.0 (motto: everything is optional! and extensible!) whereby Don Box introduced xhtml:body into his feed in place of description, something that most aggregators support today. On the other hand, what we have is arguments that entries with empty summaries is not possible with the current format - something that is blatantly incorrect. We also had a very complex and delicate negotiation a while back that seems to have been forgotten. It is quite possible to produce feeds with content that is base64 encoded binary or out of band. What is desired in such circumstances is precisely akin to specifications that require alt attributes for img tags. It atom's case, it is a summary. If you want to push through this pace, I suggest that we revisit and reopen those discussions. Schedule be damned. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Apr 26 09:56:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09574 for <atompub-archive@lists.ietf.org>; Tue, 26 Apr 2005 09:56:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QDj57S079632; Tue, 26 Apr 2005 06:45:05 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QDj50T079631; Tue, 26 Apr 2005 06:45:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QDj4qZ079611 for <atom-syntax@imc.org>; Tue, 26 Apr 2005 06:45:04 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2852592wra for <atom-syntax@imc.org>; Tue, 26 Apr 2005 06:44:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OGyh2juG6QlcWqFvkxapIrl7SQjWWLXhdqzOmPLWE2m04l27Qt7BnkKWJdgRf4hJDWkbG0nEMbi1/Rx6a0PiSf8YpXIROEQqr2pfjQ9PZhazpSMcI2xumw7aKSFLGM0H9m8lAsd8wz3t4M8RwOqdTQEWP7eymYPmpDQ5rj+nSiQ= Received: by 10.54.112.19 with SMTP id k19mr661625wrc; Tue, 26 Apr 2005 06:44:56 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 26 Apr 2005 06:44:56 -0700 (PDT) Message-ID: <68fba5c5050426064447430953@mail.gmail.com> Date: Tue, 26 Apr 2005 09:44:56 -0400 From: Robert Sayre <sayrer@gmail.com> Reply-To: Robert Sayre <sayrer@gmail.com> To: Sam Ruby <rubys@intertwingly.net> Subject: Re: PaceOptionalSummary Cc: Tim Bray <Tim.Bray@Sun.COM>, atom-syntax Syntax <atom-syntax@imc.org> In-Reply-To: <426E3FC7.3080801@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <672bc8dc873220a2070555424e9f7e4d@sun.com> <426E3FC7.3080801@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3QDj4qZ079626 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit > The feedvalidator catches silly, boring corner-cases every day. > > I hesitate to bring it up again as it has proven to incite adhominen > attacks from within this workgroup, but we have an example of a > respected journalist who has published a book in which he specifically > called out this. So? What does that have to do with interop? > > And we have the experience from RSS 2.0 (motto: everything is optional! > and extensible!) whereby Don Box introduced xhtml:body into his feed in > place of description, something that most aggregators support today. Yes, and he just might stick xaml:body in there next year. We can't stop him. > On the other hand, what we have is arguments that entries with empty > summaries is not possible with the current format - something that is > blatantly incorrect. Well, the argument was originally that people don't like title-only feeds, so we shouldn't even worry about them (see journalist point above). > > We also had a very complex and delicate negotiation a while back that > seems to have been forgotten. It is quite possible to produce feeds > with content that is base64 encoded binary or out of band. What is > desired in such circumstances is precisely akin to specifications that > require alt attributes for img tags. It atom's case, it is a summary. I've edited Tim's Pace to show what the resulting text would look like, since a summary would still be required in such circumstances. Hopefully, the resulting requirements are clear now. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 26 11:40:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19612 for <atompub-archive@lists.ietf.org>; Tue, 26 Apr 2005 11:40:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QFVKnN097217; Tue, 26 Apr 2005 08:31:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QFVKj1097216; Tue, 26 Apr 2005 08:31:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QFVJLF097210 for <atom-syntax@imc.org>; Tue, 26 Apr 2005 08:31:19 -0700 (PDT) (envelope-from jtauber@jtauber.com) Received: from web2.messagingengine.com (web2.internal [10.202.2.211]) by frontend1.messagingengine.com (Postfix) with ESMTP id D35FCC7804E; Tue, 26 Apr 2005 11:31:17 -0400 (EDT) Received: by web2.messagingengine.com (Postfix, from userid 99) id 5B71B2BE1; Tue, 26 Apr 2005 11:31:12 -0400 (EDT) Message-Id: <1114529472.26966.232752756@webmail.messagingengine.com> X-Sasl-Enc: bT0xC7SrsMtiIcjwvcNQurful8ftmXXnDotaNeRO0nXx 1114529472 From: "James Tauber" <jtauber@jtauber.com> To: "Sam Ruby" <rubys@intertwingly.net> Cc: "atom-syntax Syntax" <atom-syntax@imc.org> Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.001; A1.64; B3.05; Q3.03) Subject: Re: PaceOptionalSummary In-Reply-To: <426E3FC7.3080801@intertwingly.net> Date: Tue, 26 Apr 2005 23:31:12 +0800 References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <672bc8dc873220a2070555424e9f7e4d@sun.com> <426E3FC7.3080801@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Does much of this debate come down simply to whether there is a distinction between an empty summary and an absence of a summary? I am in favour of an optional summary because if there is no summary, I would rather not see <summary/> I can understand that people that don't have a problem with <summary/> meaning "no summary" would not see any reason to make it optional. James -- James Tauber http://jtauber.com/ journeyman of some http://jtauber.com/blog/ From owner-atom-syntax@mail.imc.org Tue Apr 26 15:43:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10872 for <atompub-archive@lists.ietf.org>; Tue, 26 Apr 2005 15:43:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QJXj2p040689; Tue, 26 Apr 2005 12:33:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QJXiPG040688; Tue, 26 Apr 2005 12:33:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QJXhsG040660 for <atom-syntax@imc.org>; Tue, 26 Apr 2005 12:33:44 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so102639wri for <atom-syntax@imc.org>; Tue, 26 Apr 2005 12:33:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=l20bYDEexmOYJPRz+Wx2ji/KTkpUzLTIgdu0xNsWTnCq/VXl3XNoWZn1bbGgvu0QhglTmdGXRWxc2JgXhnCV3NMrEvGmLo75zkuN0Hjr0Iat4kjMMJahed8jCQ1e1r3p1kmXtypWgbL9qiO/FxDFRyL1qRnHr/nQ+ISNLaqPTmw= Received: by 10.54.118.16 with SMTP id q16mr68253wrc; Tue, 26 Apr 2005 12:33:38 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Tue, 26 Apr 2005 12:33:38 -0700 (PDT) Message-ID: <540e3732050426123310883142@mail.gmail.com> Date: Tue, 26 Apr 2005 14:33:38 -0500 From: "Roger B." <rogben@gmail.com> Reply-To: "Roger B." <rogben@gmail.com> To: atom-syntax Syntax <atom-syntax@imc.org> Subject: Re: PaceOptionalSummary In-Reply-To: <6d885e8145db474ec35d402a3b2d3b91@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3QJXisG040682 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit I'd be willing give a +1 to SHOULD language regarding summary/content. I'd prefer one or the other be required for a weblog-centric format like Atom, but I'll just do what I already do with title-only RSS feeds... have my code reject them as inadequate. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Tue Apr 26 15:47:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11177 for <atompub-archive@lists.ietf.org>; Tue, 26 Apr 2005 15:47:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QJZQox040965; Tue, 26 Apr 2005 12:35:26 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QJZQbd040964; Tue, 26 Apr 2005 12:35:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QJZPiF040947 for <atom-syntax@imc.org>; Tue, 26 Apr 2005 12:35:25 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so103888wri for <atom-syntax@imc.org>; Tue, 26 Apr 2005 12:35:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dYe/ACuHseo1z9+X9NfzJuqEfXT2B7miFePGdM+VIcTyw/p5tZR+jtO6+fSLtJYGkxVIbYdclncOnf7orO4NAb54oza0Qm6S8sEEJyY5//KcOoQ6Ad5YUShJaijnGUCJxgXbFcek2v5F7ortrFdylLcdRaENxihx0VAx9oKThSY= Received: by 10.54.119.10 with SMTP id r10mr56321wrc; Tue, 26 Apr 2005 12:35:19 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Tue, 26 Apr 2005 12:35:19 -0700 (PDT) Message-ID: <540e3732050426123511a28fca@mail.gmail.com> Date: Tue, 26 Apr 2005 14:35:19 -0500 From: "Roger B." <rogben@gmail.com> Reply-To: "Roger B." <rogben@gmail.com> To: atom-syntax Syntax <atom-syntax@imc.org> Subject: Re: PaceOptionalSummary In-Reply-To: <68fba5c505042604143f4e8e82@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <672bc8dc873220a2070555424e9f7e4d@sun.com> <68fba5c505042604143f4e8e82@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3QJZPiF040959 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit > Do the following messages mean the same thing? Robert: In my app? Yep, exactly the same. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Tue Apr 26 16:01:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12295 for <atompub-archive@lists.ietf.org>; Tue, 26 Apr 2005 16:01:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QJt0E9044156; Tue, 26 Apr 2005 12:55:00 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QJt01A044154; Tue, 26 Apr 2005 12:55:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QJsx08044131 for <atom-syntax@imc.org>; Tue, 26 Apr 2005 12:54:59 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so109414wra for <atom-syntax@imc.org>; Tue, 26 Apr 2005 12:54:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CAOdjdWNjwnMlGrTKyqJw8GfyPsERTHwgOVkyxRyA843oditfbb2RRemCBltM+vv5VvaGVXtMUXHM9hjAbiPG6PjlVzNrpB0nwcxn6JVdPAZDtOs0Bhf4v01tALu2B/LTkULLY42OvTyksSmq43TjOHPn9BquCrfgF4lFdknCow= Received: by 10.54.112.12 with SMTP id k12mr71556wrc; Tue, 26 Apr 2005 12:54:53 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 26 Apr 2005 12:54:53 -0700 (PDT) Message-ID: <68fba5c505042612547933e9c5@mail.gmail.com> Date: Tue, 26 Apr 2005 15:54:53 -0400 From: Robert Sayre <sayrer@gmail.com> Reply-To: Robert Sayre <sayrer@gmail.com> To: "Roger B." <rogben@gmail.com> Subject: Re: PaceOptionalSummary Cc: atom-syntax Syntax <atom-syntax@imc.org> In-Reply-To: <540e3732050426123310883142@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3QJsx08044141 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit On 4/26/05, Roger B. <rogben@gmail.com> wrote: > > I'd be willing give a +1 to SHOULD language regarding summary/content. That's not good enough. You have to demonstrate an interop problem to say SHOULD or MUST. > I'd prefer one or the other be required for a weblog-centric format > like Atom, but I'll just do what I already do with title-only RSS > feeds... have my code reject them as inadequate. Just like it would reject an entry containing <summary/>, since it means the same thing, right? You yourself send them: http://www.imc.org/atom-syntax/mail-archive/msg14147.html They are clearly adequate for some class of applications, so please demonstrate the interoperability problems they cause. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 26 17:02:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17045 for <atompub-archive@lists.ietf.org>; Tue, 26 Apr 2005 17:02:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QKo8nr053249; Tue, 26 Apr 2005 13:50:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QKo8Cx053248; Tue, 26 Apr 2005 13:50:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QKo7LQ053229 for <atom-syntax@imc.org>; Tue, 26 Apr 2005 13:50:08 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3QKnctQ006019; Tue, 26 Apr 2005 21:49:49 +0100 (BST) In-Reply-To: <68fba5c505042612547933e9c5@mail.gmail.com> References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <bbc7007faf120310f367760ecfaf53e6@mac.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax <atom-syntax@imc.org> From: Graham <dtcd@mac.com> Subject: Re: PaceOptionalSummary Date: Tue, 26 Apr 2005 21:49:22 +0100 To: Robert Sayre <sayrer@gmail.com> X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 26 Apr 2005, at 8:54 pm, Robert Sayre wrote: > On 4/26/05, Roger B. <rogben@gmail.com> wrote: >> >> I'd be willing give a +1 to SHOULD language regarding summary/content. > > That's not good enough. You have to demonstrate an interop problem to > say SHOULD or MUST. So your app sends me an Atom document that looks like this: <entry> <id>whetever</id> <title>So Caleb is Lindsey's father What does this mean? a) A title only feed b) A full entry with the summary missing. Without knowing this (which it wouldn't under Tim's proposal), my app can't reliably interoperate with yours. (Why does my app need to know? None of our business) Graham From owner-atom-syntax@mail.imc.org Tue Apr 26 17:24:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18936 for ; Tue, 26 Apr 2005 17:24:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QL6gqj056222; Tue, 26 Apr 2005 14:06:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QL6gi7056221; Tue, 26 Apr 2005 14:06:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3QL6ekI056203 for ; Tue, 26 Apr 2005 14:06:41 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 26 Apr 2005 21:06:31 -0000 Received: from xdsl-213-196-247-103.netcologne.de (EHLO klangraum) [213.196.247.103] by mail.gmx.net (mp002) with SMTP; 26 Apr 2005 23:06:31 +0200 X-Authenticated: #163624 Date: Tue, 26 Apr 2005 23:09:33 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: PaceOptionalSummary Message-ID: <20050426210933.GB24347@klangraum> Mail-Followup-To: atom-syntax References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Graham [2005-04-26 23:00]: > So your app sends me an Atom document that looks like this: > > > whetever > So Caleb is Lindsey's father > > > What does this mean? That’s invalid, since it’s missing both an atom:content as well as an atom:link[@rel='alternate']. It must have one or the other. > a) A title only feed > b) A full entry with the summary missing. > > Without knowing this (which it wouldn't under Tim's proposal), > my app can't reliably interoperate with yours. How would supplying a token change anything about the meaning? Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Tue Apr 26 17:26:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19218 for ; Tue, 26 Apr 2005 17:26:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLFOKa057984; Tue, 26 Apr 2005 14:15:25 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QLFNk2057979; Tue, 26 Apr 2005 14:15:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLFMNf057741 for ; Tue, 26 Apr 2005 14:15:23 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc11) with SMTP id <2005042621144501100f7cufe>; Tue, 26 Apr 2005 21:14:45 +0000 Date: Tue, 26 Apr 2005 15:14:43 -0600 Subject: Re: PaceOptionalSummary Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tuesday, April 26, 2005, at 02:49 PM, Graham wrote: > So your app sends me an Atom document that looks like this: > > > whetever > So Caleb is Lindsey's father > > > What does this mean? > > a) A title only feed > b) A full entry with the summary missing. > > Without knowing this (which it wouldn't under Tim's proposal), my app > can't reliably interoperate with yours. > What if you get this: whetever So Caleb is Lindsey's father DNA testing has proven Caleb is Lindsey's father What does this mean? a) a title and summary only entry b) a full content entry with the content missing c) a summary and extension element entry with dc:modified missing etc. etc. etc. As long as an entry meets the requirements of the spec, if an element isn't there, the consumer (unless it has some special out-of-band knowledge) has to assume that the entry is complete. If anything that the publisher intended to have there is missing, then their software has a bug or they've misconfigured it, and ensuring that their buggy or incorrectly configured software interoperates well is beyond the scope of the spec, is it not? From owner-atom-syntax@mail.imc.org Tue Apr 26 17:42:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20451 for ; Tue, 26 Apr 2005 17:42:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLZoov061259; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QLZoMB061258; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLZnrx061235 for ; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3QLOfYZ016023; Tue, 26 Apr 2005 22:24:47 +0100 (BST) In-Reply-To: <68fba5c505042613534b9e1ade@mail.gmail.com> References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <68fba5c505042613534b9e1ade@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: PaceOptionalSummary Date: Tue, 26 Apr 2005 22:24:38 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote: > On 4/26/05, Graham wrote: >> Without knowing this (which it wouldn't under Tim's proposal), my app >> can't reliably interoperate with yours. > > I have no idea what you're talking about. Do the feeds on > craigslist.org interoperate? Yes or No? Interoperate with what? If I write an app that needs to know whether an entry had a body that was removed or is a title-only feed, it cannot interoperate with Atom feeds under Tim's proposal because there is no difference between them. This is totally an interoperability issue. Graham From owner-atom-syntax@mail.imc.org Tue Apr 26 17:49:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21174 for ; Tue, 26 Apr 2005 17:49:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLfa7o062245; Tue, 26 Apr 2005 14:41:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QLfaiq062244; Tue, 26 Apr 2005 14:41:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLfZri062223 for ; Tue, 26 Apr 2005 14:41:35 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so167953wra for ; Tue, 26 Apr 2005 14:41:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CxnPeGOBoQsMVE1ZdqngI0aQH7XcgKaYudnnZDPO4nXjE968Prk0aZD2cdKRhPozLriixn0+8/otUWPTSLlYmHicjMd9W/tCB5HIthtNfzDNBjNp11QpRFWZ+K48Pr16z7nLIlOLi7v/QcqdyeMoWCp6Btaj8ogD9rJep0+D3nA= Received: by 10.54.78.16 with SMTP id a16mr138515wrb; Tue, 26 Apr 2005 14:41:26 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 26 Apr 2005 14:41:26 -0700 (PDT) Message-ID: <68fba5c505042614414d34d4d3@mail.gmail.com> Date: Tue, 26 Apr 2005 17:41:26 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: PaceOptionalSummary Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <68fba5c505042613534b9e1ade@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3QLfZri062239 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/26/05, Graham wrote: > If I write an app that needs to know whether an entry had a body that > was removed or is a title-only feed, uh, what's the difference. > it cannot interoperate with Atom > feeds under Tim's proposal because there is no difference between them. > This is totally an interoperability issue. Nonsense. None of Atom's elements communicate that information, and there is no requirement to do so. Next. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 26 19:01:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27548 for ; Tue, 26 Apr 2005 19:01:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QMqBRf074467; Tue, 26 Apr 2005 15:52:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QMqBUv074466; Tue, 26 Apr 2005 15:52:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3QMqAJY074444 for ; Tue, 26 Apr 2005 15:52:10 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 27371 messnum 5763667 invoked from network[83.70.217.193/unknown]); 26 Apr 2005 22:52:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail12.svc.cra.dublin.eircom.net (qp 27371) with SMTP; 26 Apr 2005 22:52:04 -0000 Message-ID: <426EC60F.10406@dehora.net> Date: Tue, 26 Apr 2005 23:51:59 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Robert Sayre , atom-syntax Subject: Re: PaceOptionalSummary References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <68fba5c505042613534b9e1ade@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote: > >> On 4/26/05, Graham wrote: >> >>> Without knowing this (which it wouldn't under Tim's proposal), my app >>> can't reliably interoperate with yours. >> >> >> I have no idea what you're talking about. Do the feeds on >> craigslist.org interoperate? Yes or No? > > > Interoperate with what? > > If I write an app that needs to know whether an entry had a body that > was removed or is a title-only feed, it cannot interoperate with Atom > feeds under Tim's proposal because there is no difference between them. > This is totally an interoperability issue. I'm not sure what you're saying is sensible. If you wrote that app, you've gone beyond anything Atom format mandates. Getting on board with your app would induce bug compatability, not interop. cheers Bill From owner-atom-syntax@mail.imc.org Tue Apr 26 19:58:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05161 for ; Tue, 26 Apr 2005 19:58:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QNmJ9Q083842; Tue, 26 Apr 2005 16:48:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QNmJbB083841; Tue, 26 Apr 2005 16:48:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QNmIds083831 for ; Tue, 26 Apr 2005 16:48:18 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so238179wri for ; Tue, 26 Apr 2005 16:48:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EEsV/7oEGIZ5Wegm1TO0YMZRoL8ZuL/mWxd/m0akp+xQr68dRFbwLZq0y+N1bCoJSwchtVlDf7fsqybLY0XeOquLWs2PTLIUq5p/6nBWuM07l//WmUfVV2nYt9d/erfqwwR921WJ/DqRt3PFBywo6mzGbH3+ScQi31CqBAw5Bqk= Received: by 10.54.83.1 with SMTP id g1mr211935wrb; Tue, 26 Apr 2005 16:48:12 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Tue, 26 Apr 2005 16:48:12 -0700 (PDT) Message-ID: <540e373205042616487e57ecfc@mail.gmail.com> Date: Tue, 26 Apr 2005 18:48:12 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax Syntax Subject: Re: PaceOptionalSummary In-Reply-To: <68fba5c505042612547933e9c5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3QNmIds083836 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > That's not good enough. You have to demonstrate an interop problem to > say SHOULD or MUST. Interop with *what*, Robert? What's the baseline? No aggregator *requires* a title... one can be synthesized. No aggregator *requires* an id... links, hashes, and so on do the job sufficiently for most purposes. No aggregator *requires* a date... if one's not attached, we can just slap on the date we acquired the entry. And so on... I honestly can't think of a single child of atom:entry that is required for interop. In which case, the only MUST in the spec would be "atom:entry MUST contain at least one child element of some kind. Have fun with that." No one needs Atom for producing a title-and-link feed. It's overkill, and pointless. The juice in Atom is in the handling of content... providing for explicit summaries, and clearly defined payload types. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Tue Apr 26 20:09:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06171 for ; Tue, 26 Apr 2005 20:09:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QNxmJh086254; Tue, 26 Apr 2005 16:59:48 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QNxmdr086253; Tue, 26 Apr 2005 16:59:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3QNxktd086246 for ; Tue, 26 Apr 2005 16:59:47 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 26 Apr 2005 23:59:41 -0000 Received: from xdsl-213-196-247-103.netcologne.de (EHLO klangraum) [213.196.247.103] by mail.gmx.net (mp031) with SMTP; 27 Apr 2005 01:59:41 +0200 X-Authenticated: #163624 Date: Wed, 27 Apr 2005 02:02:43 +0200 From: "A. Pagaltzis" To: atom-syntax Syntax Subject: Re: PaceOptionalSummary Message-ID: <20050427000243.GB7998@klangraum> Mail-Followup-To: atom-syntax Syntax References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6d885e8145db474ec35d402a3b2d3b91@sun.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Tim Bray [2005-04-25 20:35]: > I decided it would help if there was an actual Pace: > http://www.intertwingly.net/wiki/pie/PaceOptionalSummary So far I haven’t seen a cogent explanation of the significant semantics offered by an empty atom:summary inside an otherwise valid minimum atom:entry (with an atom:id, atom:title, and atom:link[@rel='alternate']). Near as I can tell, there is no discernible difference between an empty and an absent summary (given the presence of the mandatory other information!). Tentatively +1. I also suggest that any cogent explanation would need to be put on record in the spec, to alert implementors to the issues and guide them to an educated choice. Otherwise, they are likely to disregard this issue either wilfully or out of negligence. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Tue Apr 26 20:29:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07253 for ; Tue, 26 Apr 2005 20:29:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0M77e088861; Tue, 26 Apr 2005 17:22:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R0M7e3088860; Tue, 26 Apr 2005 17:22:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0M7EA088821 for ; Tue, 26 Apr 2005 17:22:07 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc11) with SMTP id <2005042700215801300debf2e>; Wed, 27 Apr 2005 00:21:58 +0000 Date: Tue, 26 Apr 2005 18:21:57 -0600 Subject: Re: PaceOptionalSummary Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <540e373205042616487e57ecfc@mail.gmail.com> Message-Id: <5D7B8090-B6B2-11D9-874E-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tuesday, April 26, 2005, at 05:48 PM, Roger B. wrote: >> That's not good enough. You have to demonstrate an interop problem to >> say SHOULD or MUST. > > Interop with *what*, Robert? What's the baseline? Interop with other Atom processing software. The spec is the baseline. The requirements of the spec are (hoepfully!) based on what's needed to enable apps to share feeds in a useful way. Let's see how losing an element other than summary might affect interop--atom:id. If entries don't have atom:id, then consumers will have to jump through all sorts of hoops to determine whether one entry is the same as one seen before, or an updated version of one seen before, or something completely new. Any actions that depend on whether Entry A == Entry B or not would be at the mercy of an app's ability to correctly divine whether they're the same entry or not. Dropping the requirement for atom:id would clearly have a negative impact on interoperability. How would an entry not having neither atom:summary nor atom:content cause problems? "Apps that expect all feeds to have a summary or content would choke" isn't a convincing argument because it's circular. If title and link feeds are allowed by the spec, then apps that can't handle them are broken. When their author's become aware that title and link feeds are possible, I can't fathom they'd have too much trouble fixing their apps. > No one needs Atom for producing a title-and-link feed. It's overkill, > and pointless. The juice in Atom is in the handling of content... > providing for explicit summaries, and clearly defined payload types. So if you don't want to provide a summary or content, go away. RSS can have you? Atom is only overkill if we require a lot of elements that aren't needed for interop. From owner-atom-syntax@mail.imc.org Tue Apr 26 20:32:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07424 for ; Tue, 26 Apr 2005 20:32:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0RCTx089628; Tue, 26 Apr 2005 17:27:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R0RCTG089627; Tue, 26 Apr 2005 17:27:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0RBZq089613 for ; Tue, 26 Apr 2005 17:27:11 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so234882wra for ; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pUjpCLEfrGrdyD5CVqTQ5eT9pvp7fophehPIyD2vrjJx1sOgc2pn2t92/tWnh/3ysKZMkNH92L/gmTbbn1KM22xRlBiX3ybEHjOVvDjr4NauW1h7hLre67IOTrp5Ox2Fwyk5h9dnjR/gaKr82Gz8sS8mXs+SxP+5ciBKawQ5wjU= Received: by 10.54.120.13 with SMTP id s13mr193998wrc; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) Message-ID: <68fba5c50504261727634cbbb9@mail.gmail.com> Date: Tue, 26 Apr 2005 20:27:05 -0400 From: Robert Sayre Reply-To: Robert Sayre To: "Roger B." Subject: Re: PaceOptionalSummary Cc: atom-syntax Syntax In-Reply-To: <540e373205042616487e57ecfc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <540e373205042616487e57ecfc@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3R0RBZq089622 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/26/05, Roger B. wrote: > And so on... I honestly can't think of a single child of atom:entry > that is required for interop. Yeah, I agree. The WG does not, however. They do happen to agree with me on this issue. > No one needs Atom for producing a title-and-link feed. It's overkill, > and pointless. The juice in Atom is in the handling of content... > providing for explicit summaries, and clearly defined payload types. The juice in Atom has little to do with the syndication format. IDs and dates are big, though. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 26 20:40:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08077 for ; Tue, 26 Apr 2005 20:40:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0ZAkq090845; Tue, 26 Apr 2005 17:35:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R0ZAiL090844; Tue, 26 Apr 2005 17:35:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0Z9cr090820 for ; Tue, 26 Apr 2005 17:35:10 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3R0Y07q029212 for ; Wed, 27 Apr 2005 01:34:06 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceOptionalSummary Date: Wed, 27 Apr 2005 01:33:55 +0100 To: atom-syntax X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This argument has a got a bit sidetracked. My position is: a) I think title-only feeds should be allowed where there's nothing sensible to put in the summary or content elements. b) Under all other circumstances, a summary of some kind should be required when atom-based textual content is absent. The pace as written newly allows the omission of a summary and content on the whim of the publisher. It also allows its omission when the content of the entry has been placed in a non-atom container. My first problem is that neither of these consequences seem intended. My second is that it is the interopability issue. I'm within my rights as a consumer to reject title-only feeds as not worth bothering with (before you condemn this as an arbitrary decision, bear in mind the current Atom spec makes the same judgement). The atom spec would not give publishers fair warning of this. This is why I think it makes more sense as a "SHOULD" requirement. (btw The list of scenarios reprinted in the Pace doesn't mention whether you MAY include atom:summary outside the MUST cases) Graham From owner-atom-syntax@mail.imc.org Tue Apr 26 22:10:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14580 for ; Tue, 26 Apr 2005 22:10:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R22tv1004718; Tue, 26 Apr 2005 19:02:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R22t1s004715; Tue, 26 Apr 2005 19:02:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R22smO004704; Tue, 26 Apr 2005 19:02:55 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@ms8.netsolmail.com [216.168.230.180] (may be forged)) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j3R22rTh023500; Tue, 26 Apr 2005 22:02:54 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DAL56613; Tue, 26 Apr 2005 22:02:53 -0400 (EDT) Message-Id: <200504270202.DAL56613@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Paul Hoffman'" , "'Atom WG'" Subject: RE: DSig (was: Comments on atompub-format-08 (Modified by Tim Bray)) Date: Tue, 26 Apr 2005 22:02:48 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVJrqyrBWZ7yzPhRcO/QZolfhAFUQBHPeEg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > The intermediary can, however, add a signed extension that > says "this message was earlier signed by Xyzzy, and we verified that > signature before we changed things." Forgive me if I'm missing something obvious... While I understand that such a statement could be generated in theory, it is not obvious to me what the precise syntax for writing such a statement would be given just what is said about signatures in the Atom draft. It seems to me that we would have to either adopt additional syntax from some currently not-referenced spec, or we'd have to define a new extension. What would you propose is the correct way to get interoperable statements such as the ones you suggest in your note? >> One other *significant* limitation in Atom's support for signatures >> is that there is no way for an intermediary to add to or otherwise modify >> an Atom entry without breaking the signature. > That's a purposeful design property of digital signatures. The exact > same issue has long affected secure mail forwarders using S/MIME or > OpenPGP. But, the problem is slightly less painful in S/MIME applications since you can wrap a signed message in an attachment while providing additional data in the envelope. Atom doesn't provide a similar mechanism. bob wyman From owner-atom-syntax@mail.imc.org Tue Apr 26 22:14:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14750 for ; Tue, 26 Apr 2005 22:14:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R28t9c005599; Tue, 26 Apr 2005 19:08:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R28tAW005598; Tue, 26 Apr 2005 19:08:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R28sKo005592 for ; Tue, 26 Apr 2005 19:08:54 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3R2CnPD026873; Tue, 26 Apr 2005 22:12:53 -0400 Message-ID: <426EF42C.5010505@intertwingly.net> Date: Tue, 26 Apr 2005 22:08:44 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: atom-syntax Subject: Re: PaceOptionalSummary References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > This argument has a got a bit sidetracked. My position is: > > a) I think title-only feeds should be allowed where there's nothing > sensible to put in the summary or content elements. > b) Under all other circumstances, a summary of some kind should be > required when atom-based textual content is absent. > > The pace as written newly allows the omission of a summary and content > on the whim of the publisher. It also allows its omission when the > content of the entry has been placed in a non-atom container. My first > problem is that neither of these consequences seem intended. My second > is that it is the interopability issue. I'm within my rights as a > consumer to reject title-only feeds as not worth bothering with (before > you condemn this as an arbitrary decision, bear in mind the current Atom > spec makes the same judgement). The atom spec would not give publishers > fair warning of this. This is why I think it makes more sense as a > "SHOULD" requirement. Well stated. I'd also add that apparently summary SHOULD be non empty in all of the cases where it is currently required as well as one new case: the case where the content is empty. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Apr 26 22:22:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15023 for ; Tue, 26 Apr 2005 22:22:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R2Fwbg006557; Tue, 26 Apr 2005 19:15:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R2FwRB006556; Tue, 26 Apr 2005 19:15:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R2Fv0M006544 for ; Tue, 26 Apr 2005 19:15:57 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so272333wra for ; Tue, 26 Apr 2005 19:15:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fIw1ZohmT3Dwv8mRNLj4r7gmu1TWGS4Fr6SvblS97w68/lXPr1LldXGJJxwCAif240fMfA5Vn3RFwEgj94Wmh9+Rp6auA0Uw1vMm2Jw77W5aYYZ8XgsguxTLQsgGSLMs9fW1WmadWmzn5wCuWpj8mPt/AcTr9nuZ/ZwBk/eAt2Q= Received: by 10.54.120.16 with SMTP id s16mr271959wrc; Tue, 26 Apr 2005 19:15:52 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 26 Apr 2005 19:15:52 -0700 (PDT) Message-ID: <68fba5c505042619152ad7b5f6@mail.gmail.com> Date: Tue, 26 Apr 2005 22:15:52 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: PaceOptionalSummary Cc: Graham , atom-syntax In-Reply-To: <426EF42C.5010505@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> <426EF42C.5010505@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3R2Fw0M006551 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/26/05, Sam Ruby wrote: > > Graham wrote: > > > > The pace as written newly allows the omission of a summary and content > > on the whim of the publisher. That's right. > > I'm within my rights as a > > consumer to reject title-only feeds as not worth bothering with (before > > you condemn this as an arbitrary decision, bear in mind the current Atom > > spec makes the same judgement). It is arbitrary. My point is that the spec does not reflect consensus in this working group or help interop. You're within your rights to reject anything, you just want the spec to back you up, and that's ridiculous. > > The atom spec would not give publishers > > fair warning of this. This is why I think it makes more sense as a > > "SHOULD" requirement. > > Well stated. I'd also add that apparently summary SHOULD be non empty > in all of the cases where it is currently required as well as one new > case: the case where the content is empty. Nonsense. Never. There are plenty of people here disagreeing with you. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 26 22:27:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15314 for ; Tue, 26 Apr 2005 22:27:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R2Js8d007182; Tue, 26 Apr 2005 19:19:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R2JsQw007181; Tue, 26 Apr 2005 19:19:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-110-114.cruzio.com [63.249.110.114]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R2JqCe007164; Tue, 26 Apr 2005 19:19:52 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200504270202.DAL56613@ms8.netsolmail.com> References: <200504270202.DAL56613@ms8.netsolmail.com> Date: Tue, 26 Apr 2005 19:19:49 -0700 To: , "'Atom WG'" From: Paul Hoffman Subject: RE: DSig (was: Comments on atompub-format-08 (Modified by Tim Bray)) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:02 PM -0400 4/26/05, Bob Wyman wrote: >Paul Hoffman wrote: >> The intermediary can, however, add a signed extension that >> says "this message was earlier signed by Xyzzy, and we verified that >> signature before we changed things." > Forgive me if I'm missing something obvious... While I understand >that such a statement could be generated in theory, it is not obvious to me >what the precise syntax for writing such a statement would be given just >what is said about signatures in the Atom draft. It seems to me that we >would have to either adopt additional syntax from some currently >not-referenced spec, or we'd have to define a new extension. What would you >propose is the correct way to get interoperable statements such as the ones >you suggest in your note? The latter (an extension). Sorry if I didn't make that clear. > >> One other *significant* limitation in Atom's support for signatures >>> is that there is no way for an intermediary to add to or otherwise modify >>> an Atom entry without breaking the signature. >> That's a purposeful design property of digital signatures. The exact >> same issue has long affected secure mail forwarders using S/MIME or >> OpenPGP. > But, the problem is slightly less painful in S/MIME applications >since you can wrap a signed message in an attachment while providing >additional data in the envelope. Atom doesn't provide a similar mechanism. Correct, but the pain is certainly still there for S/MIME and OpenPGP. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Tue Apr 26 22:52:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17728 for ; Tue, 26 Apr 2005 22:52:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R2Tk26008601; Tue, 26 Apr 2005 19:29:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R2Tkb9008600; Tue, 26 Apr 2005 19:29:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R2TiSt008585 for ; Tue, 26 Apr 2005 19:29:45 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so277231wra for ; Tue, 26 Apr 2005 19:29:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IUlsgRbJJagvhEzNcStWn9lZVK0vmkjvBTnQJuSrqbblO2yvNMtHAbUje3TYFuBvfONMIDzd+s9SnnHRLoGceWDuHpHZIaTmdAXyP9BgzrKkqdkU0MFLwAaITXP9nH1zblrnZIc2YABk1RPBiO5rN48AMyKFw8reSeAatfCta/U= Received: by 10.54.120.12 with SMTP id s12mr278571wrc; Tue, 26 Apr 2005 19:29:39 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 26 Apr 2005 19:29:39 -0700 (PDT) Message-ID: <68fba5c50504261929339880ae@mail.gmail.com> Date: Tue, 26 Apr 2005 22:29:39 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: PaceOptionalSummary Cc: atom-syntax Syntax In-Reply-To: <672bc8dc873220a2070555424e9f7e4d@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <672bc8dc873220a2070555424e9f7e4d@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3R2TjSt008595 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/26/05, Tim Bray wrote: > > Paul & I are gonna watch a little more debate and then > we'll call rough consensus one way or the other, at which point I at > least will become crushingly rude to anyone who wants to invest more > time in this. Yeah, so now Sam and Graham are off making up requirements to add to the spec. This is over and its a waste of the WG's time. Let me summarize: MUST: Sam SHOULD: Graham, Roger Eh: Bill MAY: Myself, James T, Antone, Eric, Julian, Martin, Aristotle Robert Sayre From owner-atom-syntax@mail.imc.org Tue Apr 26 23:53:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21492 for ; Tue, 26 Apr 2005 23:53:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R3fcro021242; Tue, 26 Apr 2005 20:41:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R3fcZs021241; Tue, 26 Apr 2005 20:41:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R3fbLM021235 for ; Tue, 26 Apr 2005 20:41:37 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3R2ca9s029745; Tue, 26 Apr 2005 22:38:36 -0400 Message-ID: <426EFA35.8010103@intertwingly.net> Date: Tue, 26 Apr 2005 22:34:29 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax Subject: Re: PaceOptionalSummary References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> <426EF42C.5010505@intertwingly.net> <68fba5c505042619152ad7b5f6@mail.gmail.com> In-Reply-To: <68fba5c505042619152ad7b5f6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > On 4/26/05, Sam Ruby wrote: > >>Graham wrote: >> >>>The pace as written newly allows the omission of a summary and content >>>on the whim of the publisher. > > > That's right. > > >>>I'm within my rights as a >>>consumer to reject title-only feeds as not worth bothering with (before >>>you condemn this as an arbitrary decision, bear in mind the current Atom >>>spec makes the same judgement). > > > It is arbitrary. My point is that the spec does not reflect consensus > in this working group or help interop. You're within your rights to > reject anything, you just want the spec to back you up, and that's > ridiculous. > > >>>The atom spec would not give publishers >>>fair warning of this. This is why I think it makes more sense as a >>>"SHOULD" requirement. >> >>Well stated. I'd also add that apparently summary SHOULD be non empty >>in all of the cases where it is currently required as well as one new >>case: the case where the content is empty. > > Nonsense. Never. There are plenty of people here disagreeing with you. If you attempt to syndicate a contentless and summaryless entry, there will be people who drop it on the floor. It doesn't matter how many people write software that behaves otherwise, it is a reality that some will behave this way. From RFC 2119: SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I am willing to concede that there are valid reasons in particular circumstances to ignore the requirement for a summary. Are you willing to concede that there are implications to such a decision that must be understood and carefully weighed before chosing to omit a summary? - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Apr 27 00:57:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25152 for ; Wed, 27 Apr 2005 00:57:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R4naU5031148; Tue, 26 Apr 2005 21:49:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R4na3n031147; Tue, 26 Apr 2005 21:49:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R4nYMb031139 for ; Tue, 26 Apr 2005 21:49:35 -0700 (PDT) (envelope-from mnot@mnot.net) Received: from [172.16.1.5] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 7B065A32B9; Wed, 27 Apr 2005 00:49:33 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5accfe2ba41fc1b5b34a02df1a1df199@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: For review: application/atom+xml Date: Tue, 26 Apr 2005 21:49:31 -0700 To: Tim Bray X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 On Apr 25, 2005, at 5:10 PM, Tim Bray wrote: > > > On Apr 25, 2005, at 3:49 PM, Mark Nottingham wrote: > >> >> Comments on the media type template. > > He's got a point on the namespace being mentioned, which creates some > semi-circular dependencies, sigh. As to whether it's currently in > use, largely due to lobbying from us, recent releases of both Apache > and IIS tie the application/atom+xml media type to the .atom > extension, so if people are creating 0.3 files and calling them > whatever.atom, this could be right. Having said that, I think we > should push back. Because any such current usage is unlicensed by any > spec, & because we plan to aggressively deprecate Atom 0.3 once we get > 1.0 out and since I suspect that 90% of 0.3 feeds come from one place > we should have some success. -Tim > >> >> Begin forwarded message: >> >>> From: Mark Baker >>> Date: April 20, 2005 11:13:54 AM PDT >>> To: ietf-types@alvestrand.no >>> Cc: iesg@ietf.org >>> Subject: Re: For review: application/atom+xml >>> >>> [ CC: IESG, since I suppose this counts as a last call comment ] >>> >>> Mark, >>> >>> Congrats on going to last call with the atompub format! - >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt >>> >>> But I note that my comment[1] on the lack of any mention of the >>> existing >>> use of application/atom+xml with the incompatible Atom 0.3 content >>> didn't make it in. Though not widespread, my understanding (though >>> I'd >>> be happy to be corrected!), at least at the time that you first drew >>> up >>> this media type[2], was that it was in use[3]. I certainly don't >>> feel >>> that this is a big enough problem to warrant a new media type, but I >>> do >>> think it should be flagged to implementors. >>> >>> Also, I noticed something else that I missed my first time through >>> ... >>> >>> On Wed, Apr 06, 2005 at 08:41:08PM -0700, Mark Nottingham wrote: >>>> Additional information: >>>> >>>> Magic number(s): As specified for "application/xml" in [RFC3023], >>>> section 3.2. >>> >>> Based on my understanding of the purpose of magic numbers, I think >>> referencing another spec's magic number algorithm to be prima facie >>> incorrect. What I think should be there is information that, as >>> uniquely as possible, identifies Atom documents, and RFC 3023 can, of >>> course, only help with identifying XML documents. So I'd suggest >>> either >>> adding something about the root namespace value (if indeed the spec >>> requires that the root element always be from the Atom namespace?) >>> as I >>> did for XHTML[4], or else just saying "Magic Number: None" (as we did >>> for SOAP[5], in effect, by not providing an algorithm). >>> >>> Cheers, >>> >>> [1] >>> http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/ >>> 000678.html >>> [2] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html >>> [3] http://diveintomark.org/archives/2003/12/13/atom03 >>> [4] http://www.ietf.org/rfc/rfc3236.txt >>> [5] http://www.ietf.org/rfc/rfc3902.txt >>> >>> Mark. >>> -- >>> Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca >>> >>> >> >> -- >> Mark Nottingham Principal Technologist >> Office of the CTO BEA Systems >> >> > - Tim Bray, Director of Web Technologies, Sun Microsystems > +1-877-305-0889 Sun ext. 60561 > http://www.tbray.org/ongoing/ AIM: MarkupPedant > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Wed Apr 27 03:06:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08249 for ; Wed, 27 Apr 2005 03:06:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R6s6JB086827; Tue, 26 Apr 2005 23:54:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R6s68P086826; Tue, 26 Apr 2005 23:54:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R6s5E8086811 for ; Tue, 26 Apr 2005 23:54:06 -0700 (PDT) (envelope-from jtauber@jtauber.com) Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id C6268C78F6B; Wed, 27 Apr 2005 02:54:04 -0400 (EDT) X-Sasl-enc: cvVx2YEvEeMLXKkAl0Ok6D0taVDZxM1gKfNfNg0BDA+E1NipoUSY 1114584844 Received: from [64.134.59.231] (dhcp64-134-59-231.burl.bos.wayport.net [64.134.59.231]) by frontend2.messagingengine.com (Postfix) with ESMTP id E7A8D570147; Wed, 27 Apr 2005 02:54:03 -0400 (EDT) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 27 Apr 2005 02:54:02 -0400 Subject: Re: PaceOptionalSummary From: James Tauber To: Sam Ruby CC: atom-syntax Message-ID: In-Reply-To: <426EFA35.8010103@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26/4/05 10:34 PM, "Sam Ruby" wrote: > I am willing to concede that there are valid reasons in particular > circumstances to ignore the requirement for a summary. Are you willing > to concede that there are implications to such a decision that must be > understood and carefully weighed before chosing to omit a summary? (I know this was addressed to Robert, but...) While I agree that the implications of a decision to omit a summary need to be understood and carefully weighed by the feed author, I don't believe that mandating the summary element actually achieves this. I would rather someone with a titles-only feed just not have a summary rather than them try to subvert the requirement of the spec by saying or (worse, if it is required to be non-empty) some useless text just put here to appease the atom spec If someone omits a summary, it is either intentional or not. The spec can either mandate the summary or not (perhaps encouraging it via a SHOULD): A. If omission is unintentional and the spec mandates it, then a validator will pick the unintentional omission. B. If the omission is unintentional and the spec doesn't mandate it, then a validator could still optionally warn the user. C. If the omission is intentional and the spec doesn't mandate it, the feed author is free to just omit it (and turn off a warning a validator might provide) D. If the omission is intentional and the spec does mandate it, then the feed author will just subvert this requirement with an empty summary or one with useless text. BC seem more acceptable to me than AD (calendarial puns unintentional) James -- James Tauber http://jtauber.com/ journeyman of some http://jtauber.com/blog/ From owner-atom-syntax@mail.imc.org Wed Apr 27 06:29:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22458 for ; Wed, 27 Apr 2005 06:29:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RALtQU076446; Wed, 27 Apr 2005 03:21:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RALtal076445; Wed, 27 Apr 2005 03:21:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RALsDc076435 for ; Wed, 27 Apr 2005 03:21:55 -0700 (PDT) (envelope-from brett.lindsley@labs.mot.com) Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j3RAOL24013873 for ; Wed, 27 Apr 2005 03:24:21 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j3RAOoGB018001 for ; Wed, 27 Apr 2005 05:24:50 -0500 (CDT) Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j3RALrVp007911 for ; Wed, 27 Apr 2005 05:21:53 -0500 (CDT) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0IFL00AKJOSG5Y@ims1.labs.mot.com> for atom-syntax@imc.org; Wed, 27 Apr 2005 05:21:52 -0500 (CDT) Date: Wed, 27 Apr 2005 05:21:52 -0500 From: Brett Lindsley Subject: Re: PaceOptionalSummary To: atom-syntax Message-id: <426F67C0.5070701@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT One reason for title only feeds is to address bandwidth limited devices. The server I set up provides the same feed in two different formats - one title only and the other with title/summary/etc. The end client can decide which feed it wants to work with based on its capabilities; however, both feeds need to be Atom spec compliant. The only thing needed for interop is some minimal useful information to indicate what the entry is (Title), the ID to identify uniqueness and a time stamp (updated) to indicate time ordering. Everything else simply adds more richness to the entry; some may be used by the end client and some may not. For example, sending entries with summarys may not be of any value to a device with limited display/storage capabilities, so why require it when it only chews up transmission bandwidth? Brett Lindsley, Motorola Labs. From owner-atom-syntax@mail.imc.org Wed Apr 27 06:41:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23654 for ; Wed, 27 Apr 2005 06:41:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RAZZte082519; Wed, 27 Apr 2005 03:35:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RAZZxu082518; Wed, 27 Apr 2005 03:35:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RAZYn6082510 for ; Wed, 27 Apr 2005 03:35:35 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3RAdSVZ021890 for ; Wed, 27 Apr 2005 06:39:36 -0400 Message-ID: <426F6AE9.60908@intertwingly.net> Date: Wed, 27 Apr 2005 06:35:21 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: PaceOptionalSummary Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James Tauber wrote: > While I agree that the implications of a decision to omit a summary need to > be understood and carefully weighed by the feed author, I don't believe that > mandating the summary element actually achieves this So.. can we agree on SHOULD? - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Apr 27 06:41:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23729 for ; Wed, 27 Apr 2005 06:41:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RAXupK081651; Wed, 27 Apr 2005 03:33:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RAXuFZ081650; Wed, 27 Apr 2005 03:33:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3RAXtkM081601 for ; Wed, 27 Apr 2005 03:33:56 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 42876 messnum 11070244 invoked from network[213.94.211.166/dev2.mcpps.com]); 27 Apr 2005 10:33:49 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail11.svc.cra.dublin.eircom.net (qp 42876) with SMTP; 27 Apr 2005 10:33:49 -0000 Message-ID: <426F6A89.80001@dehora.net> Date: Wed, 27 Apr 2005 11:33:45 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: PaceOptionalSummary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James Tauber wrote: > BC seem more acceptable to me than AD (calendarial puns unintentional) I agree with this line of thought - and great pun! It's one thing to reduce optionality, it's another to encourage garbage out. Sam mentioned earlier that people will drop title-only feeds on the floor; befoe wondering whether that's reasonable behaviour do we have a list anywhere? cheers Bill From owner-atom-syntax@mail.imc.org Wed Apr 27 06:42:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23886 for ; Wed, 27 Apr 2005 06:42:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RAb4J3083177; Wed, 27 Apr 2005 03:37:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RAb4V9083176; Wed, 27 Apr 2005 03:37:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3RAb367083126 for ; Wed, 27 Apr 2005 03:37:03 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 64754 messnum 6387762 invoked from network[213.94.211.166/dev2.mcpps.com]); 27 Apr 2005 10:36:57 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail00.svc.cra.dublin.eircom.net (qp 64754) with SMTP; 27 Apr 2005 10:36:57 -0000 Message-ID: <426F6B46.1060109@dehora.net> Date: Wed, 27 Apr 2005 11:36:54 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Mark Nottingham , Atom Syntax Subject: Re: For review: application/atom+xml References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > > On Apr 25, 2005, at 3:49 PM, Mark Nottingham wrote: > >> >> Comments on the media type template. > > > Having said that, I think we should push back. > Because any such current usage is unlicensed by any spec, & because we > plan to aggressively deprecate Atom 0.3 once we get 1.0 out and since I > suspect that 90% of 0.3 feeds come from one place we should have some > success. -Tim +1 cheers Bill From owner-atom-syntax@mail.imc.org Wed Apr 27 07:47:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28185 for ; Wed, 27 Apr 2005 07:47:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RBeUZO007123; Wed, 27 Apr 2005 04:40:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RBeU53007122; Wed, 27 Apr 2005 04:40:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RBeThY007111 for ; Wed, 27 Apr 2005 04:40:29 -0700 (PDT) (envelope-from jtauber@jtauber.com) Received: from web2.messagingengine.com (web2.internal [10.202.2.211]) by frontend1.messagingengine.com (Postfix) with ESMTP id E4954C7996A; Wed, 27 Apr 2005 07:40:27 -0400 (EDT) Received: by web2.messagingengine.com (Postfix, from userid 99) id 41096813; Wed, 27 Apr 2005 07:40:24 -0400 (EDT) Message-Id: <1114602024.25138.232826811@webmail.messagingengine.com> X-Sasl-Enc: Mct0gmQrVbqq9UDFUFQJGUN5gWWqpyrxT4WvmyouIgXj 1114602024 From: "James Tauber" To: "Sam Ruby" , "atom-syntax" Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.001; A1.64; B3.05; Q3.03) References: <426F6AE9.60908@intertwingly.net> Subject: Re: PaceOptionalSummary In-Reply-To: <426F6AE9.60908@intertwingly.net> Date: Wed, 27 Apr 2005 19:40:24 +0800 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 27 Apr 2005 06:35:21 -0400, "Sam Ruby" said: > > While I agree that the implications of a decision to omit a summary need to > > be understood and carefully weighed by the feed author, I don't believe that > > mandating the summary element actually achieves this > > So.. can we agree on SHOULD? Well, given how close what I've said I agree to is to the wording of RFC 2119, I'll look inconsistent if I don't say 'yes' :-) I could certainly live with SHOULD. James -- James Tauber http://jtauber.com/ journeyman of some http://jtauber.com/blog/ From owner-atom-syntax@mail.imc.org Wed Apr 27 09:14:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09410 for ; Wed, 27 Apr 2005 09:14:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RD6ghd037141; Wed, 27 Apr 2005 06:06:42 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RD6grQ037140; Wed, 27 Apr 2005 06:06:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3RD6e74037121 for ; Wed, 27 Apr 2005 06:06:41 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 27 Apr 2005 13:06:34 -0000 Received: from xdsl-213-196-254-200.netcologne.de (EHLO klangraum) [213.196.254.200] by mail.gmx.net (mp030) with SMTP; 27 Apr 2005 15:06:34 +0200 X-Authenticated: #163624 Date: Wed, 27 Apr 2005 15:09:38 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: PaceOptionalSummary Message-ID: <20050427130938.GA5087@klangraum> Mail-Followup-To: atom-syntax References: <426F6AE9.60908@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426F6AE9.60908@intertwingly.net> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Sam Ruby [2005-04-27 12:45]: > So.. can we agree on SHOULD? +1. My previous tentative +1 for MAY is hereby withdrawn. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Wed Apr 27 09:33:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11018 for ; Wed, 27 Apr 2005 09:33:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RDQ74O039257; Wed, 27 Apr 2005 06:26:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RDQ7WF039256; Wed, 27 Apr 2005 06:26:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.afp.com (smtp2.afp.com [158.50.208.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RDQ64C039247 for ; Wed, 27 Apr 2005 06:26:06 -0700 (PDT) (envelope-from laurent.lemeur@afp.com) Received: by smtp2.afp.com (Sendmail, from userid 1007) id D7EAA46A8A; Wed, 27 Apr 2005 15:25:44 +0200 (CEST) Received: from alox.afp.com (unknown [158.50.165.141])by smtp2.afp.com (Sendmail) with ESMTP id 9A76646A89for ; Wed, 27 Apr 2005 15:25:44 +0200 (CEST) Received: from stdc05bis ([158.50.180.254])by alox.afp.com (8.12.9/8.12.9) with ESMTP id j3RDPSWu020201for ; Wed, 27 Apr 2005 15:25:33 +0200 (METDST) Message-Id: <200504271325.j3RDPSWu020201@alox.afp.com> From: "Laurent Le Meur" To: "'Atom Syntax'" Subject: IPTC News Metadata Framework Requirements specification issued for comment Date: Wed, 27 Apr 2005 15:25:32 +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.2180 Thread-index: AcVF2V7LDflxLfnQTmyjHr6JXzuUUgAAz1bQAVNjpPA= X-MailScanner: Found to be clean Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Atomes, One of the goal of the Atom initiative is to obtain a simple but powerful way to handle metadata. The International Press Telecommunications Council (IPTC) studies the same kind of problems in the domain of professional news-worthy information, and we feel that the Atom WG could be interested in commenting the work of IPTC members on this subject. The News Metadata Framework Working Group of the International Press Telecommunications Council (IPTC) has released the first public draft of its News Metadata Framework Requirements specification, for review and discussion. This is the first step ("what do we need, really?") in the development of a detailed XML Metadata Framework in the news domain. The News Metadata Framework forms part of the IPTC News Architecture initiative. This initiative will lead to a new generation of IPTC standards, including NewsML2 (representation of general news) and EventsML (representation of news events and coverage of these events). The document is available at: www.iptc.org/download/public/DRAFT-NAR_1.0-spec-NMDF-BusinessRequ_26.pdf We welcome your comments: - at the News Standards Summit, in Amsterdam, on 24 May 2005: http://www.newssummit.org - on the iptc-metadata mailing list: http://groups.yahoo.com/group/iptc-metadata Laurent Le Meur Head of Medialab, AFP Chair, News architecture WP, IPTC -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Wed Apr 27 10:20:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18899 for ; Wed, 27 Apr 2005 10:20:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3REAqDL042454; Wed, 27 Apr 2005 07:10:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3REAqCA042453; Wed, 27 Apr 2005 07:10:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3REApRc042440 for ; Wed, 27 Apr 2005 07:10:52 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc13) with SMTP id <20050427141045016002kkn1e>; Wed, 27 Apr 2005 14:10:45 +0000 Date: Wed, 27 Apr 2005 08:10:43 -0600 Subject: Re: PaceOptionalSummary Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <426F67C0.5070701@labs.mot.com> Message-Id: <248F228C-B726-11D9-9B37-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, April 27, 2005, at 04:21 AM, Brett Lindsley wrote: > One reason for title only feeds is to address bandwidth limited > devices. The > server I set up provides the same feed in two different formats - one > title > only and the other with title/summary/etc. The end client can decide > which > feed it wants to work with based on its capabilities; This raises a few questions: 1) How does one indicate the existence of variants? 2) Can/should the variant feeds use the same atom:ids for variants of the same entries? 3) How does a client select a preferred variant? 4) How does an aggregator discover the "complete" and/or "authoritative" variant of an entry? Here's a quick idea for how this might be done. Especially at this late stage, this would almost certainly go in an extension. But I bring it up now because of the issue raised by question #2 could mean that the extension MIGHT be contradicting the Atom spec if it said to use the same atom:id for multiple variants, depending on one's interpretation: ... title id updated link[@rel="alternate"] title id updated link[@rel="alternate"] content[@type="html"] title id updated link[@rel="alternate"] content[@type="xhtml"] From owner-atom-syntax@mail.imc.org Wed Apr 27 10:46:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21251 for ; Wed, 27 Apr 2005 10:46:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3REcA5l044469; Wed, 27 Apr 2005 07:38:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3REcAXW044468; Wed, 27 Apr 2005 07:38:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3REc99T044459 for ; Wed, 27 Apr 2005 07:38:09 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so560158wra for ; Wed, 27 Apr 2005 07:38:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Cyzaun2TJB1+ipD9twLr5h1MvoZcdk8ssXo5VgngGW09stZizbFNeJDOu3tefi1O5eYolRnga26p5lby1p/URPP2NrBjFPxZFweGsVqAloezQ7nZ97adfLt99apx2N0nj7VCJgrFOVJwrYOlt7hOlZ2wcqbiFJPFdV1TaKYkttM= Received: by 10.54.78.16 with SMTP id a16mr553177wrb; Wed, 27 Apr 2005 07:38:03 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Wed, 27 Apr 2005 07:38:03 -0700 (PDT) Message-ID: <68fba5c505042707387c289d87@mail.gmail.com> Date: Wed, 27 Apr 2005 10:38:03 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: PaceOptionalSummary Cc: atom-syntax In-Reply-To: <426EFA35.8010103@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> <426EF42C.5010505@intertwingly.net> <68fba5c505042619152ad7b5f6@mail.gmail.com> <426EFA35.8010103@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3REc99T044462 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/26/05, Sam Ruby wrote: > If you attempt to syndicate a contentless and summaryless entry, there > will be people who drop it on the floor. It doesn't matter how many > people write software that behaves otherwise, it is a reality that some > will behave this way. Do you have an example? > > From RFC 2119: > > SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > I am willing to concede that there are valid reasons in particular > circumstances to ignore the requirement for a summary. Are you willing > to concede that there are implications to such a decision that must be > understood and carefully weighed before chosing to omit a summary? What are the interoperability considerations that must be carefully weighed? I think the "full implications" you're worried about are non-technical. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 27 10:46:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21269 for ; Wed, 27 Apr 2005 10:46:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3REblSv044431; Wed, 27 Apr 2005 07:37:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3REblj2044430; Wed, 27 Apr 2005 07:37:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from motgate7.mot.com (motgate7.mot.com [129.188.136.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3REbgvf044418 for ; Wed, 27 Apr 2005 07:37:42 -0700 (PDT) (envelope-from brett.lindsley@labs.mot.com) Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id j3REQcMq014877 for ; Wed, 27 Apr 2005 07:26:39 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j3REdB06011664 for ; Wed, 27 Apr 2005 09:39:12 -0500 (CDT) Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j3REbdVp010973; Wed, 27 Apr 2005 09:37:39 -0500 (CDT) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0IFM00A620MR5Y@ims1.labs.mot.com>; Wed, 27 Apr 2005 09:37:39 -0500 (CDT) Date: Wed, 27 Apr 2005 09:37:39 -0500 From: Brett Lindsley Subject: Re: PaceOptionalSummary To: Antone Roundy Cc: atom-syntax@imc.org Message-id: <426FA3B3.8000408@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <248F228C-B726-11D9-9B37-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT I used title="titles" and title="full" to indicate the varients in the feed discovery while maintaining compliance with the current spec. The user must select which feed to use. One assumption I am making is that the updated time for both the title only and the full entry are the same. If I have a title only entry and I want the full entry, I just use the updated time to indicate a time range in the full entry feed. I also use the same ID and verify the returned full entry matches the ID of the title only entry. Brett Lindsley, Motorola Labs Antone Roundy wrote: > > On Wednesday, April 27, 2005, at 04:21 AM, Brett Lindsley wrote: > >> One reason for title only feeds is to address bandwidth limited >> devices. The >> server I set up provides the same feed in two different formats - one >> title >> only and the other with title/summary/etc. The end client can decide >> which >> feed it wants to work with based on its capabilities; > > > This raises a few questions: > > 1) How does one indicate the existence of variants? > 2) Can/should the variant feeds use the same atom:ids for variants of > the same entries? > 3) How does a client select a preferred variant? > 4) How does an aggregator discover the "complete" and/or > "authoritative" variant of an entry? > > Here's a quick idea for how this might be done. Especially at this > late stage, this would almost certainly go in an extension. But I > bring it up now because of the issue raised by question #2 could mean > that the extension MIGHT be contradicting the Atom spec if it said to > use the same atom:id for multiple variants, depending on one's > interpretation: > > > > > > ... > > > > > title > id > updated > link[@rel="alternate"] > > > title > id > updated > link[@rel="alternate"] > content[@type="html"] > > > title > id > updated > link[@rel="alternate"] > content[@type="xhtml"] > > > From owner-atom-syntax@mail.imc.org Wed Apr 27 11:12:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23545 for ; Wed, 27 Apr 2005 11:12:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RErD23045509; Wed, 27 Apr 2005 07:53:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RErD71045508; Wed, 27 Apr 2005 07:53:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RErBZ8045499 for ; Wed, 27 Apr 2005 07:53:12 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 27 Apr 2005 19:53:15 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 28 Apr 2005 00:53:05 +1000 Subject: Re: PaceOptionalSummary From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <248F228C-B726-11D9-9B37-003065EA6144@geckotribe.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 28/4/05 12:10 AM, "Antone Roundy" wrote: > > > > > ... > why not ... and the client agent can then present these to the user to select from. e. From owner-atom-syntax@mail.imc.org Wed Apr 27 11:31:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24570 for ; Wed, 27 Apr 2005 11:31:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RFKrIC047637; Wed, 27 Apr 2005 08:20:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RFKrtF047636; Wed, 27 Apr 2005 08:20:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RFKqvu047629 for ; Wed, 27 Apr 2005 08:20:52 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc12) with SMTP id <2005042715204601200difase>; Wed, 27 Apr 2005 15:20:46 +0000 Date: Wed, 27 Apr 2005 09:20:45 -0600 Subject: Re: PaceOptionalSummary Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, April 27, 2005, at 08:53 AM, Eric Scheid wrote: > why not > > > > > > ... > > > and the client agent can then present these to the user to select from. At present: atom:feed elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same type attribute value. ...but if that were something other than "alternate"... The question is, do you want this to be automatically discoverable or only user selectable? Finding the authoritative variant automatically might be important for some applications. Finding a variant with a specific set of elements and as few others as possible might be important for other applications. That COULD be done by downloading and inspecting each variant. ...but I'm really speculating here. The main reason I brought this up now was because, given that some people are already publishing variant feeds, it might be good to answer the question of whether using the same atom:id in variants of an entry is legal, and if so, how such things should/could be handled. From owner-atom-syntax@mail.imc.org Wed Apr 27 11:55:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26370 for ; Wed, 27 Apr 2005 11:55:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RFm6U9049681; Wed, 27 Apr 2005 08:48:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RFm6m1049680; Wed, 27 Apr 2005 08:48:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RFm55r049674 for ; Wed, 27 Apr 2005 08:48:05 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j3RFm4Wj029816 for ; Wed, 27 Apr 2005 11:48:04 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DAO13916 (AUTH bob@wyman.us); Wed, 27 Apr 2005 11:48:02 -0400 (EDT) Message-Id: <200504271548.DAO13916@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'atom-syntax Syntax''" Subject: PubSub CAN NOT support Atom with existing "no duplicate id" constraint Date: Wed, 27 Apr 2005 11:48:00 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C54B1E.F6CF73E0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVLQH1nDNmAFsFIQweQXSZ0doFIvw== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C54B1E.F6CF73E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I know that nobody seems to like this issue. However, I have explained on numerous occasions that the existing prohibition against duplicate ids in a feed simply cannot be supported by PubSub or any other feed aggregator. The problem is, once again, that prohibiting duplicate ids provides an easy to use attack vector for those wishing to effectively "erase" entries written by another author. (i.e. by publishing an entry with an id identical to one published earlier, one can force the earlier entry to be flushed from Atom feeds.) If synthetic feed generators such as PubSub implement the current prohibition against duplicate ids, they will simply become open channels for attack. We'll soon see anti-abortionists publishing entries with ids identical to those of entries whose content they disapprove of. We'll see ex-boyfriends attack critical entries written by girls whom they displeased on Saturday night. We'll see skinheads "flush" from the system any entries that might have been written by jews and blacks. This is not good and I will not allow the system I build to be used in this manner. Graham Park has proposed that we loosen the existing language to permit duplicate ids in the case where the entries have atom:source elements which identify different URI's in "self" links. I support this compromise and believe it should be supported by the WG and incorporated into the Atom Draft. I don't believe the issue here is one of taste and I don't see any responsible option other then modifying the existing constraint. No one has been able to provide any argument which explains why the attack vector I describe is *NOT* a problem. If the WG refuses to modify this constraint, then it should at least feel compelled to include text in the security considerations section that clearly describes the attack and lets people know that no atom entry is "safe" from trivial attacks as a result of this constraint. If the WG refuses to modify this constraint, then they should expect that responsible feed aggregators and generators of synthetic feeds will simply be forced to deny support for Atom as specified. If anyone has a clear argument explaining why the attack is not possible or not a problem, they should make it. Alternatively, if you have a better method then that proposed by Graham for defending against the attack, please describe it. Otherwise, Graham's compromise should be accepted and the specification revised. bob wyman ------=_NextPart_000_0045_01C54B1E.F6CF73E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I know that nobody seems to = like this issue… However, I have explained on numerous occasions that = the existing prohibition against duplicate ids in a feed simply cannot be = supported by PubSub or any other feed aggregator. The problem is, once again, that prohibiting duplicate ids provides an easy to use attack vector for = those wishing to effectively “erase” entries written by another = author. (i.e. by publishing an entry with an id identical to one published earlier, = one can force the earlier entry to be flushed from Atom feeds.) =

If synthetic feed = generators such as PubSub implement the current prohibition against duplicate ids, they = will simply become open channels for attack. We’ll soon see = anti-abortionists publishing entries with ids identical to those of entries whose content = they disapprove of. We’ll see ex-boyfriends attack critical entries = written by girls whom they displeased on Saturday night. We’ll see skinheads = “flush” from the system any entries that might have been written by jews and = blacks. This is not good and I will not allow the system I build to be used in this = manner.

Graham Park has proposed = that we loosen the existing language to permit duplicate ids in the case where the = entries have atom:source elements which identify different URI’s in = “self” links. I support this compromise and believe it should be supported by = the WG and incorporated into the Atom Draft.

I don’t believe the = issue here is one of taste and I don’t see any responsible option other then modifying the existing constraint. No one has been able to provide any = argument which explains why the attack vector I describe is *NOT* a problem. If the WG refuses to modify this = constraint, then it should at least feel compelled to include text in the security considerations section that clearly describes the attack and lets people = know that no atom entry is “safe” from trivial attacks as a result of = this constraint. If the WG refuses to modify this constraint, then they = should expect that responsible feed aggregators and generators of synthetic = feeds will simply be forced to deny support for Atom as = specified.

If anyone has a clear = argument explaining why the attack is not possible or not a problem, they should = make it. Alternatively, if you have a better method then that proposed by = Graham for defending against the attack, please describe it. Otherwise, = Graham’s compromise should be accepted and the specification = revised.

 

bob = wyman

 

------=_NextPart_000_0045_01C54B1E.F6CF73E0-- From owner-atom-syntax@mail.imc.org Wed Apr 27 12:08:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27871 for ; Wed, 27 Apr 2005 12:08:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RG1Umd050547; Wed, 27 Apr 2005 09:01:30 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RG1U0M050546; Wed, 27 Apr 2005 09:01:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RG1TuR050532 for ; Wed, 27 Apr 2005 09:01:29 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 02890D2 for ; Wed, 27 Apr 2005 09:01:24 -0700 (PDT) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j3RG1Ing014392 for ; Wed, 27 Apr 2005 09:01:23 -0700 (PDT) Date: Wed, 27 Apr 2005 09:09:34 -0700 From: Walter Underwood To: atom-syntax Syntax Subject: Re: PaceOptionalSummary Message-ID: <2641A798B3AF6C7DF64C5639@diva.verity.com> In-Reply-To: <20050427000243.GB7998@klangraum> References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <20050427000243.GB7998@klangraum> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Wednesday, April 27, 2005 02:02:43 AM +0200 "A. Pagaltzis" wrote: > > So far I haven?t seen a cogent explanation of the significant > semantics offered by an empty atom:summary inside an otherwise > valid minimum atom:entry. It should be obvious. It means that when you summarize the content, you get nothing at all. It is an effectively, but not literally, content-free entry. I'm not being entirely silly here. We could distinguish between "I am not providing a summary" (no element) and "the summary is void" (empty summary). wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Wed Apr 27 12:12:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28475 for ; Wed, 27 Apr 2005 12:12:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RG64Pw051105; Wed, 27 Apr 2005 09:06:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RG64Hv051104; Wed, 27 Apr 2005 09:06:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3RG630s051087 for ; Wed, 27 Apr 2005 09:06:04 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 10214 messnum 2879076 invoked from network[213.94.211.166/dev2.mcpps.com]); 27 Apr 2005 16:05:57 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail09.svc.cra.dublin.eircom.net (qp 10214) with SMTP; 27 Apr 2005 16:05:57 -0000 Message-ID: <426FB861.6090404@dehora.net> Date: Wed, 27 Apr 2005 17:05:53 +0100 From: =?windows-1252?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'atom-syntax Syntax''" Subject: Re: PubSub CAN NOT support Atom with existing "no duplicate id" constraint References: <200504271548.DAO13916@ms8.netsolmail.com> In-Reply-To: <200504271548.DAO13916@ms8.netsolmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bob Wyman wrote: > I know that nobody seems to like this issue… However, I have explained > on numerous occasions that the existing prohibition against duplicate > ids in a feed simply cannot be supported by PubSub or any other feed > aggregator. The problem is, once again, that prohibiting duplicate ids > provides an easy to use attack vector for those wishing to effectively > “erase” entries written by another author. (i.e. by publishing an entry > with an id identical to one published earlier, one can force the earlier > entry to be flushed from Atom feeds.) > > [...] > Graham Park has proposed that we loosen the existing language to permit > duplicate ids in the case where the entries have atom:source elements > which identify different URI’s in “self” links. I support this > compromise and believe it should be supported by the WG and incorporated > into the Atom Draft. Bob, What will prevent people overwriting the atom:source[@rel='self'] links as well as the id? cheers Bill From owner-atom-syntax@mail.imc.org Wed Apr 27 12:14:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28782 for ; Wed, 27 Apr 2005 12:14:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RG5Ima051071; Wed, 27 Apr 2005 09:05:18 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RG5Iv5051070; Wed, 27 Apr 2005 09:05:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RG5HTt051064 for ; Wed, 27 Apr 2005 09:05:17 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3RG9Kb9022837; Wed, 27 Apr 2005 12:09:20 -0400 Message-ID: <426FB837.8050905@intertwingly.net> Date: Wed, 27 Apr 2005 12:05:11 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'atom-syntax Syntax''" Subject: Re: PubSub CAN NOT support Atom with existing "no duplicate id" constraint References: <200504271548.DAO13916@ms8.netsolmail.com> In-Reply-To: <200504271548.DAO13916@ms8.netsolmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bob Wyman wrote: > I know that nobody seems to like this issue… However, I have explained > on numerous occasions that the existing prohibition against duplicate > ids in a feed simply cannot be supported by PubSub or any other feed > aggregator. The problem is, once again, that prohibiting duplicate ids > provides an easy to use attack vector for those wishing to effectively > “erase” entries written by another author. (i.e. by publishing an entry > with an id identical to one published earlier, one can force the earlier > entry to be flushed from Atom feeds.) > > If synthetic feed generators such as PubSub implement the current > prohibition against duplicate ids, they will simply become open channels > for attack. We’ll soon see anti-abortionists publishing entries with ids > identical to those of entries whose content they disapprove of. We’ll > see ex-boyfriends attack critical entries written by girls whom they > displeased on Saturday night. We’ll see skinheads “flush” from the > system any entries that might have been written by jews and blacks. This > is not good and I will not allow the system I build to be used in this > manner. > > Graham Park has proposed that we loosen the existing language to permit > duplicate ids in the case where the entries have atom:source elements > which identify different URI’s in “self” links. I support this > compromise and believe it should be supported by the WG and incorporated > into the Atom Draft. > > I don’t believe the issue here is one of taste and I don’t see any > responsible option other then modifying the existing constraint. No one > has been able to provide any argument which explains why the attack > vector I describe is **NOT** a problem. If the WG refuses to modify this > constraint, then it should at least feel compelled to include text in > the security considerations section that clearly describes the attack > and lets people know that no atom entry is “safe” from trivial attacks > as a result of this constraint. If the WG refuses to modify this > constraint, then they should expect that responsible feed aggregators > and generators of synthetic feeds will simply be forced to deny support > for Atom as specified. > > If anyone has a clear argument explaining why the attack is not possible > or not a problem, they should make it. Alternatively, if you have a > better method then that proposed by Graham for defending against the > attack, please describe it. Otherwise, Graham’s compromise should be > accepted and the specification revised. It would help if a Pace could be written. IIRC, the objections to PaceRepeatIdInDocument centered around the request to support multiple versions of a resource - a concern that does not apply to Graham's proposed compromise. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Apr 27 12:16:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29104 for ; Wed, 27 Apr 2005 12:16:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RG8FaT051257; Wed, 27 Apr 2005 09:08:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RG8FOO051256; Wed, 27 Apr 2005 09:08:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3RG8Ed0051245 for ; Wed, 27 Apr 2005 09:08:14 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 91517 messnum 5274849 invoked from network[213.94.211.166/dev2.mcpps.com]); 27 Apr 2005 16:08:08 -0000 Received: from dev2.mcpps.com (HELO ?127.0.0.1?) (213.94.211.166) by mail04.svc.cra.dublin.eircom.net (qp 91517) with SMTP; 27 Apr 2005 16:08:08 -0000 Message-ID: <426FB8E4.6060409@dehora.net> Date: Wed, 27 Apr 2005 17:08:04 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Syntax Subject: Re: PaceOptionalSummary References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <20050427000243.GB7998@klangraum> <2641A798B3AF6C7DF64C5639@diva.verity.com> In-Reply-To: <2641A798B3AF6C7DF64C5639@diva.verity.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > I'm not being entirely silly here. We could distinguish between > "I am not providing a summary" (no element) and "the summary is void" > (empty summary). We could; but isn't that only really needed if we mandate the empty element, ie if we mandate the XML variant of SQL's true/false/null? cheers Bill From owner-atom-syntax@mail.imc.org Wed Apr 27 12:16:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29173 for ; Wed, 27 Apr 2005 12:16:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGBEAK051495; Wed, 27 Apr 2005 09:11:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RGBEGl051494; Wed, 27 Apr 2005 09:11:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGBDKA051485 for ; Wed, 27 Apr 2005 09:11:13 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so620309wra for ; Wed, 27 Apr 2005 09:11:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=n5ppWxoHDPT2arzzFgXk2rItbOgdNe8YONhFyicIKdRjb/rvDazP7QpL2q6nOpgk/HJg4drKlekP6XjpQ8hUdvgEe0DjnEij1xVX9CsuqA0CSCRrefVm7E6c0mUeuvZJ6VT8UtxC8IA4w3S/MTUg9NRrpzPTTveF2c1fsA/txGY= Received: by 10.54.121.17 with SMTP id t17mr239784wrc; Wed, 27 Apr 2005 09:11:05 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Wed, 27 Apr 2005 09:11:05 -0700 (PDT) Message-ID: <68fba5c50504270911ebe52cf@mail.gmail.com> Date: Wed, 27 Apr 2005 12:11:05 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: PubSub CAN NOT support Atom with existing "no duplicate id" constraint Cc: bob@wyman.us, "atom-syntax Syntax'" In-Reply-To: <426FB837.8050905@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <200504271548.DAO13916@ms8.netsolmail.com> <426FB837.8050905@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3RGBEKA051489 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/27/05, Sam Ruby wrote: > IIRC, the objections to PaceRepeatIdInDocument centered around the > request to support multiple versions of a resource - a concern that does > not apply to Graham's proposed compromise. Yes, Graham's proposal seems like a good idea to me as well. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 27 12:17:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29214 for ; Wed, 27 Apr 2005 12:17:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RG9BS6051331; Wed, 27 Apr 2005 09:09:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RG9Bj3051330; Wed, 27 Apr 2005 09:09:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RG9Bag051324 for ; Wed, 27 Apr 2005 09:09:11 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 98664 invoked by uid 17064); 27 Apr 2005 16:09:10 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.15.4]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 27 Apr 2005 16:09:10 -0000 In-Reply-To: <200504271548.DAO13916@ms8.netsolmail.com> References: <200504271548.DAO13916@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Cc: Bob Wyman From: Henry Story Subject: Re: PubSub CAN NOT support Atom with existing "no duplicate id" constraint Date: Wed, 27 Apr 2005 18:09:11 +0200 To: "'atom-syntax Syntax''" X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3RG9Bag051325 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I support this. I think we should vote on the two solutions: A- the compromise solution you propose B- the simple solution which simply allows entries with duplicate ids C- No change My preference is clearly B then A, and certainly not C. As far as I am concerned there is no interop purpose for C (the current limitation). Therefore it should be dropped. Henry On 27 Apr 2005, at 17:48, Bob Wyman wrote: > I know that nobody seems to like this issue… However, I have explained > on numerous occasions that the existing prohibition against duplicate > ids in a feed simply cannot be supported by PubSub or any other feed > aggregator. The problem is, once again, that prohibiting duplicate ids > provides an easy to use attack vector for those wishing to effectively > “erase” entries written by another author. (i.e. by publishing an > entry with an id identical to one published earlier, one can force the > earlier entry to be flushed from Atom feeds.) > If synthetic feed generators such as PubSub implement the current > prohibition against duplicate ids, they will simply become open > channels for attack. We’ll soon see anti-abortionists publishing > entries with ids identical to those of entries whose content they > disapprove of. We’ll see ex-boyfriends attack critical entries written > by girls whom they displeased on Saturday night. We’ll see skinheads > “flush” from the system any entries that might have been written by > jews and blacks. This is not good and I will not allow the system I > build to be used in this manner. > Graham Park has proposed that we loosen the existing language to > permit duplicate ids in the case where the entries have atom:source > elements which identify different URI’s in “self” links. I support > this compromise and believe it should be supported by the WG and > incorporated into the Atom Draft. > I don’t believe the issue here is one of taste and I don’t see any > responsible option other then modifying the existing constraint. No > one has been able to provide any argument which explains why the > attack vector I describe is *NOT* a problem. If the WG refuses to > modify this constraint, then it should at least feel compelled to > include text in the security considerations section that clearly > describes the attack and lets people know that no atom entry is “safe” > from trivial attacks as a result of this constraint. If the WG refuses > to modify this constraint, then they should expect that responsible > feed aggregators and generators of synthetic feeds will simply be > forced to deny support for Atom as specified. > If anyone has a clear argument explaining why the attack is not > possible or not a problem, they should make it. Alternatively, if you > have a better method then that proposed by Graham for defending > against the attack, please describe it. Otherwise, Graham’s compromise > should be accepted and the specification revised. >   > bob wyman >   From owner-atom-syntax@mail.imc.org Wed Apr 27 12:35:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00815 for ; Wed, 27 Apr 2005 12:35:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGSOhH053103; Wed, 27 Apr 2005 09:28:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RGSOGY053102; Wed, 27 Apr 2005 09:28:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGSMSo053092 for ; Wed, 27 Apr 2005 09:28:24 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 27 Apr 2005 09:28:18 -0700 To: Atom WG From: Paul Hoffman Subject: On SHOULD, MUST, and semantics Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A few brief notes for the WG to chew on. - Literal interpretation of 2119 for a document format such as Atom would make nearly every element of an entry a MAY. It is a tad dishonest to say "why is element Xyz even a SHOULD?" when we have a *long* list of MUSTs already. It is no wonder that people are changing their opinion of any particular element from MUST to MAY to SHOULD and around again. - The format document, like many IETF Applications Area specs, is steeped in hidden semantics. If I suggested that atom:title go from MUST to MAY, there would be outrage. The reason is that most of us think of entries as having some semantics that include a title. We don't say in the format document why we made atom:title a MUST: it's just "obvious". - Differentiating the importance of the semantics of various elements is really, really hard, and people's opinions change over time. I strongly suspect that many of the less-vocal-but-still-active members of this list have changed their view of the importance of atom:category at least once. This is the hardest one to align with making a simple-to implement spec. The fewer cross-element links we have, the easier it will be for an implementer. - We have, unfortunately, linked the semantics of two or more elements together. atom:content and atom:summary are linked because of their semantics (if you don't have a readable content, you MUST/SHOULD/MAY have a summary). - We have, fortunately, not required linked semantics for extensions. If I came out with hoffman:content-plus-plus, I can't assume that whatever linkage there is between atom:summary and atom:content will apply to my extension. But, of course, if someone considers hoffman:content-plus-plus to be like atom:content, they may *want* the same linkages. - Every SHOULD, by definition, adds logic into the software that creates a message in the spec'd format. In the long history of the IETF, this also tends to prevent interop, because it gives two differing parties a soapbox to argue from. - Person A may think that an optional element that is missing means W. Person B may think that an optional element that is present but null means X. Person C may think that W == X, Person D may think that W != X. Person C and Person D will probably code very differently. Proposal for thinking about: to simplify the spec, "atom:summary" should either be a MUST in all cases or a MAY in all cases. If it is just semantic like "atom:category", it should be a MAY. If it is inherently valuable like "atom:title", it should be a MUST. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Apr 27 12:43:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01363 for ; Wed, 27 Apr 2005 12:43:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGapTv054040; Wed, 27 Apr 2005 09:36:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RGapNR054039; Wed, 27 Apr 2005 09:36:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGam4w054020; Wed, 27 Apr 2005 09:36:49 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200504271548.DAO13916@ms8.netsolmail.com> References: <200504271548.DAO13916@ms8.netsolmail.com> Date: Wed, 27 Apr 2005 09:36:46 -0700 To: , "'atom-syntax Syntax''" From: Paul Hoffman Subject: Re: PubSub CAN NOT support Atom with existing "no duplicate id" constraint Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit At 11:48 AM -0400 4/27/05, Bob Wyman wrote: >I know that nobody seems to like this issueŠ However, I have >explained on numerous occasions that the existing prohibition >against duplicate ids in a feed simply cannot be supported by PubSub >or any other feed aggregator. The problem is, once again, that >prohibiting duplicate ids provides an easy to use attack vector for >those wishing to effectively "erase" entries written by another >author. (i.e. by publishing an entry with an id identical to one >published earlier, one can force the earlier entry to be flushed >from Atom feeds.) Question (not a disagreement): Why wouldn't the later entry be dropped instead of the first one being flushed? At 5:05 PM +0100 4/27/05, Bill de hÓra wrote: >What will prevent people overwriting the atom:source[@rel='self'] >links as well as the id? Seems like a good question. If someone is trying every avenue to erase an old entry, why wouldn't they try this as well? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Apr 27 12:47:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01635 for ; Wed, 27 Apr 2005 12:47:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGdbmc054204; Wed, 27 Apr 2005 09:39:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RGdbUJ054203; Wed, 27 Apr 2005 09:39:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGdaus054193 for ; Wed, 27 Apr 2005 09:39:36 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j3RGdYmm011208; Wed, 27 Apr 2005 12:39:34 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DAO38612 (AUTH bob@wyman.us); Wed, 27 Apr 2005 12:39:33 -0400 (EDT) Message-Id: <200504271639.DAO38612@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "=?iso-8859-1?Q?'Bill_de_h=D3ra'?=" , "'atom-syntax Syntax''" Subject: RE: PubSub CAN NOT support Atom with existing "no duplicate id" constraint Date: Wed, 27 Apr 2005 12:39:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVLRM0Nbu3x3ltAREWyHWJU1lAFZQAATRtw In-Reply-To: <426FB861.6090404@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3RGdbus054196 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > What will prevent people overwriting the atom:source[@rel='self'] links > as well as the id? Now you see why Graham Park's proposal is a "compromise." It improves things but doesn't provide a definitive solution to all cases. It means a great deal more processing for us, but at least allows us to defend against this form of attack. Certainly, people could rewrite the links and certainly they will if we modify the existing constraint to require it. However, I expect that at PubSub, we'll insist on verifying the existence the entry in the reputed source before we publish any entry with an atom:source[@rel='self'] link that we haven't generated ourselves. (We will insert atom:source into *every* entry we publish to ensure that attribution is properly provided.) Alternatively, we'll insist on the entry being signed with a key which is known to be associated with the claimed source feed. (We're still working on the mechanisms by which keys would be associated with blogs.) I haven't yet decided what to do in the case where we can't confirm that the entry actually comes from the claimed source or someone who is authorized to publish in the claimed source. We may publish the suspect entry with a new id or we may simply discard the suspect entry. What do you suggest? Any ideas you may have for handling these cases would be appreciated. bob wyman From owner-atom-syntax@mail.imc.org Wed Apr 27 12:47:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01656 for ; Wed, 27 Apr 2005 12:47:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGeCTG054259; Wed, 27 Apr 2005 09:40:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RGeCW3054258; Wed, 27 Apr 2005 09:40:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGeBju054252 for ; Wed, 27 Apr 2005 09:40:11 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 27 Apr 2005 21:40:14 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 28 Apr 2005 02:40:04 +1000 Subject: Re: PubSub CAN NOT support Atom with existing "no duplicate id" constraint From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 28/4/05 2:09 AM, "Henry Story" wrote: > B- the simple solution which simply allows entries with duplicate > ids +1 From owner-atom-syntax@mail.imc.org Wed Apr 27 12:54:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02303 for ; Wed, 27 Apr 2005 12:54:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGnj24054937; Wed, 27 Apr 2005 09:49:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RGnj7M054936; Wed, 27 Apr 2005 09:49:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGniwB054914; Wed, 27 Apr 2005 09:49:45 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3RGrlOW027611; Wed, 27 Apr 2005 12:53:47 -0400 Message-ID: <426FC2A3.6000108@intertwingly.net> Date: Wed, 27 Apr 2005 12:49:39 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Atom WG Subject: Re: On SHOULD, MUST, and semantics References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > > - We have, unfortunately, linked the semantics of two or more elements > together. atom:content and atom:summary are linked because of their > semantics (if you don't have a readable content, you MUST/SHOULD/MAY > have a summary). > > - We have, fortunately, not required linked semantics for extensions. If > I came out with hoffman:content-plus-plus, I can't assume that whatever > linkage there is between atom:summary and atom:content will apply to my > extension. But, of course, if someone considers > hoffman:content-plus-plus to be like atom:content, they may *want* the > same linkages. Actually, that's one of the key reasons why I like the MUST for summary. If somebody invents a popular hoffman:content-plus-plus, then feeds that include it lieu of atom:content will need to include a human readable summary that can be used by existing clients. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Apr 27 13:00:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03001 for ; Wed, 27 Apr 2005 13:00:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGoGnL054966; Wed, 27 Apr 2005 09:50:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RGoGdF054965; Wed, 27 Apr 2005 09:50:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGoDYV054957 for ; Wed, 27 Apr 2005 09:50:15 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id C6821C2 for ; Wed, 27 Apr 2005 09:50:08 -0700 (PDT) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j3RGo8ng015054 for ; Wed, 27 Apr 2005 09:50:08 -0700 (PDT) Date: Wed, 27 Apr 2005 09:58:24 -0700 From: Walter Underwood To: atom-syntax Subject: Re: PaceOptionalSummary Message-ID: <261584087C5D4EA8C0C6C84B@diva.verity.com> In-Reply-To: <68fba5c505042707387c289d87@mail.gmail.com> References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> <426EF42C.5010505@intertwingly.net> <68fba5c505042619152ad7b5f6@mail.gmail.com> <426EFA35.8010103@intertwingly.net> <68fba5c505042707387c289d87@mail.gmail.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Wednesday, April 27, 2005 10:38:03 AM -0400 Robert Sayre wrote: >> I am willing to concede that there are valid reasons in particular >> circumstances to ignore the requirement for a summary. Are you willing >> to concede that there are implications to such a decision that must be >> understood and carefully weighed before chosing to omit a summary? > > What are the interoperability considerations that must be carefully > weighed? I think the "full implications" you're worried about are > non-technical. It certainly makes the feed much less useful for some kinds of applications. I work on a search engine, and, for us, a titles-only feed is very different one with content or summaries. A titles-only feed is basically a pretty version of "ls". The engine follows the links, but does not index the document. With summaries or content, the feed is a document in its own right, and it makes sense to index it under its own URL. A search engine won't ignore a titles-only feed, but it is less likely to treat it as a first-class document. Now I'm going to go re-read the PACE to see where I am on +/-. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Wed Apr 27 13:00:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03019 for ; Wed, 27 Apr 2005 13:00:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGkr84054719; Wed, 27 Apr 2005 09:46:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RGkraN054718; Wed, 27 Apr 2005 09:46:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RGkpwT054712 for ; Wed, 27 Apr 2005 09:46:53 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 27 Apr 2005 09:46:49 -0700 To: Atom WG From: Paul Hoffman Subject: RESEND: On SHOULD, MUST, and semantics Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [[ Bad content error in my first draft; resending ]] A few brief notes for the WG to chew on. - Literal interpretation of 2119 for a document format such as Atom would make nearly every element of an entry a MAY. It is a tad dishonest to say "why is element Xyz even a SHOULD?" when we have a *long* list of MUSTs already. It is no wonder that people are changing their opinion of any particular element from MUST to MAY to SHOULD and around again. - The format document, like many IETF Applications Area specs, is steeped in hidden semantics. If I suggested that atom:title go from MUST to MAY, there would be outrage. The reason is that most of us think of entries as having some semantics that include a title. We don't say in the format document why we made atom:title a MUST: it's just "obvious". - Differentiating the importance of the semantics of various elements is really, really hard, and people's opinions change over time. I strongly suspect that many of the less-vocal-but-still-active members of this list have changed their view of the importance of atom:category at least once. - We have, unfortunately, linked the semantics of two or more elements together. atom:content and atom:summary are linked because of their semantics (if you don't have a readable content, you MUST/SHOULD/MAY have a summary). This is the hardest one to align with making a simple-to implement spec. The fewer cross-element links we have, the easier it will be for an implementer. - We have, fortunately, not required linked semantics for extensions. If I came out with hoffman:content-plus-plus, I can't assume that whatever linkage there is between atom:summary and atom:content will apply to my extension. But, of course, if someone considers hoffman:content-plus-plus to be like atom:content, they may *want* the same linkages. - Every SHOULD, by definition, adds logic into the software that creates a message in the spec'd format. In the long history of the IETF, this also tends to prevent interop, because it gives two differing parties a soapbox to argue from. - Person A may think that an optional element that is missing means W. Person B may think that an optional element that is present but null means X. Person C may think that W == X, Person D may think that W != X. Person C and Person D will probably code very differently. Proposal for thinking about: to simplify the spec, "atom:summary" should either be a MUST in all cases or a MAY in all cases. If it is just semantic like "atom:category", it should be a MAY. If it is inherently valuable like "atom:title", it should be a MUST. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Apr 27 13:10:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03649 for ; Wed, 27 Apr 2005 13:10:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RH0L05055990; Wed, 27 Apr 2005 10:00:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RH0Lj0055989; Wed, 27 Apr 2005 10:00:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RH0KlJ055979; Wed, 27 Apr 2005 10:00:21 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j3RH0HTj020354; Wed, 27 Apr 2005 13:00:19 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DAO47820 (AUTH bob@wyman.us); Wed, 27 Apr 2005 13:00:15 -0400 (EDT) Message-Id: <200504271700.DAO47820@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Paul Hoffman'" , , "'atom-syntax Syntax''" Subject: RE: PubSub CAN NOT support Atom with existing "no duplicate id" constraint Date: Wed, 27 Apr 2005 13:00:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVLR1RbfqYLO+PNTCanpT3rsIza/wAAb+Ow In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3RH0LlJ055980 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Paul Hoffman wrote: > Question (not a disagreement): Why wouldn't the later entry be > dropped instead of the first one being flushed? The order of entries is not significant for the subject attack. The reason is that it is possible for an attacker to mount an "anticipatory" attack by discovering and predicting the atom:ids that will be generated by a publisher under attack. In the simplest case, the author under attack might use an id generating method that distinguished between ids by simply incrementing a counter. Thus, if you knew the id of the last item published, you could generate a "blocking" entry that used what was probably going to be the next id generated. The fake id would block "real" posts if the rule was to always drop the second or later instance of an id. This permits the attacker to impose a prior-restraint or anticipatory block against a publisher. Also, strict enforcement of this rule would make it virtually impossible for a legitimate "update" to an entry to ever get propagated through the system. In the case of legitimate updates, I'm sure people would argue that the older entry should be dropped, not the newer one. >At 5:05 PM +0100 4/27/05, Bill de hÓra wrote: >>What will prevent people overwriting the atom:source[@rel='self'] >>links as well as the id? > Seems like a good question. If someone is trying every avenue to > erase an old entry, why wouldn't they try this as well? This is answered in full in my previous email to the list. Basically, the aggregator would have to verify the truth of the claim made in the atom:source[@rel='self'] before republishing the entry. This is cumbersome and expensive, but will often be possible. bob wyman From owner-atom-syntax@mail.imc.org Wed Apr 27 13:17:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04150 for ; Wed, 27 Apr 2005 13:17:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RH9rwl056745; Wed, 27 Apr 2005 10:09:53 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RH9rdj056744; Wed, 27 Apr 2005 10:09:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RH9qHR056728 for ; Wed, 27 Apr 2005 10:09:53 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so659074wra for ; Wed, 27 Apr 2005 10:09:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aQVYUULwhlloF7Q3aO/iaUA20k2RMljyTGT4/6EK8iys+zhcD74JSr/zhwA09lXwqm9l3Y9CNXuhOwcnXwMmTYHOwAWIAHk1H5svZ87sJfvdlbkIu88VVspNG8ZQUxQMCrm/Mnf+05iYyh4k6zy1ODvXuBuqOoJh8tHFqVLsc7o= Received: by 10.54.120.9 with SMTP id s9mr265398wrc; Wed, 27 Apr 2005 10:03:07 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Wed, 27 Apr 2005 10:03:07 -0700 (PDT) Message-ID: <68fba5c50504271003b63ab2d@mail.gmail.com> Date: Wed, 27 Apr 2005 13:03:07 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: On SHOULD, MUST, and semantics Cc: Paul Hoffman , Atom WG In-Reply-To: <426FC2A3.6000108@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426FC2A3.6000108@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3RH9rHR056731 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/27/05, Sam Ruby wrote: > Actually, that's one of the key reasons why I like the MUST for summary. > If somebody invents a popular hoffman:content-plus-plus, then feeds > that include it lieu of atom:content will need to include a human > readable summary that can be used by existing clients. If they nest a content-plus-plus inside atom:content, they wouldn't have to include that summary, right? Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 27 13:56:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06861 for ; Wed, 27 Apr 2005 13:56:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RHndwv059634; Wed, 27 Apr 2005 10:49:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RHndLK059633; Wed, 27 Apr 2005 10:49:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RHnb5Y059618; Wed, 27 Apr 2005 10:49:38 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3RHlcIm016149; Wed, 27 Apr 2005 18:47:44 +0100 (BST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: On SHOULD, MUST, and semantics Date: Wed, 27 Apr 2005 18:47:37 +0100 To: Paul Hoffman X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27 Apr 2005, at 5:28 pm, Paul Hoffman wrote: > Proposal for thinking about: to simplify the spec, "atom:summary" > should either be a MUST in all cases or a MAY in all cases. If it is > just semantic like "atom:category", it should be a MAY. If it is > inherently valuable like "atom:title", it should be a MUST. What isn't "inherently valuable" about a "semantic". False dichotomy. What a load of unconstructive bollocks. Graham From owner-atom-syntax@mail.imc.org Wed Apr 27 14:06:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07783 for ; Wed, 27 Apr 2005 14:06:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RHuRXs060023; Wed, 27 Apr 2005 10:56:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RHuReD060022; Wed, 27 Apr 2005 10:56:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RHuQU6060009 for ; Wed, 27 Apr 2005 10:56:26 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc13) with SMTP id <20050427175621015004jkgie>; Wed, 27 Apr 2005 17:56:21 +0000 Date: Wed, 27 Apr 2005 11:56:20 -0600 Subject: Re: PubSub CAN NOT support Atom with existing "no duplicate id" constraint Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <200504271639.DAO38612@ms8.netsolmail.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, April 27, 2005, at 10:39 AM, Bob Wyman wrote: > Certainly, people could rewrite the links and certainly they will if > we modify the existing constraint to require it. However, I expect > that at > PubSub, we'll insist on verifying the existence the entry in the > reputed > source before we publish any entry with an atom:source[@rel='self'] > link > that we haven't generated ourselves. If PubSub is subscribed to the feed pointed to by atom:source[@rel='self'], then can't you simply drop any entries claiming to be from that feed but found at a different URI? You'll be getting those entries from the source if they're legitimate, so is there any reason to accept them from elsewhere? Or are you keeping them in case they contain additional information added by someone else? BTW, I'm in favor of the compromise solution. From owner-atom-syntax@mail.imc.org Wed Apr 27 14:27:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09174 for ; Wed, 27 Apr 2005 14:27:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RIAW1i062450; Wed, 27 Apr 2005 11:10:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RIAWRB062449; Wed, 27 Apr 2005 11:10:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RIAVFt062429 for ; Wed, 27 Apr 2005 11:10:31 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3RI9wTn023569; Wed, 27 Apr 2005 19:10:03 +0100 (BST) In-Reply-To: <200504271700.DAO47820@ms8.netsolmail.com> References: <200504271700.DAO47820@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: PubSub CAN NOT support Atom with existing "no duplicate id" constraint Date: Wed, 27 Apr 2005 19:09:57 +0100 To: bob@wyman.us X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27 Apr 2005, at 6:00 pm, Bob Wyman wrote: > Paul Hoffman wrote: >> Question (not a disagreement): Why wouldn't the later entry be >> dropped instead of the first one being flushed? > The order of entries is not significant for the subject attack. The > reason is that it is possible for an attacker to mount an > "anticipatory" > attack by discovering and predicting the atom:ids that will be > generated by > a publisher under attack. In the simplest case, the author under attack > might use an id generating method that distinguished between ids by > simply > incrementing a counter. Thus, if you knew the id of the last item > published, > you could generate a "blocking" entry that used what was probably > going to > be the next id generated. The fake id would block "real" posts if the > rule > was to always drop the second or later instance of an id. This permits > the > attacker to impose a prior-restraint or anticipatory block against a > publisher. After years of dealing with seriously crappy RSS feeds, aggregator authors are smart enough to know everything in a feed is merely a hint and should not be not be trusted. This attack is not worth worrying about, though for completeness may be worth mentioning in the security section. Graham Parks From owner-atom-syntax@mail.imc.org Wed Apr 27 14:35:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10096 for ; Wed, 27 Apr 2005 14:35:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RISJhL065307; Wed, 27 Apr 2005 11:28:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RISJdH065306; Wed, 27 Apr 2005 11:28:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RISIHw065295 for ; Wed, 27 Apr 2005 11:28:18 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j3RISGqr009153; Wed, 27 Apr 2005 14:28:17 -0400 (EDT) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DAO85414 (AUTH bob@wyman.us); Wed, 27 Apr 2005 14:28:11 -0400 (EDT) Message-Id: <200504271828.DAO85414@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Graham'" Cc: "'atom-syntax'" Subject: RE: PubSub CAN NOT support Atom with existing "no duplicate id" constraint Date: Wed, 27 Apr 2005 14:28:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVLVG238UQSUpnQSmOGGd9HYB0vZgAAYpnw In-Reply-To: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Parks wrote: > After years of dealing with seriously crappy RSS feeds, aggregator > authors are smart enough to know everything in a feed is merely a hint > and should not be not be trusted. This attack is not worth worrying > about, though for completeness may be worth mentioning in the security > section. You may be happy to have your aggregator susceptible to such attacks; however, I can't accept having my aggregator similarly compromised. My users expect and demand a higher level of service from PubSub than they get from other feed providers and aggregators... However strictly we may interpret the contents of feeds, the feed format itself should be defined in such a manner so that an aggregator that strictly interprets the specification will work properly when presented with conforming feeds. In the absence of evidence that the proposed change will result in damage or interoperability problems, I think the spec must change. A security note is not sufficient. bob wyman From owner-atom-syntax@mail.imc.org Wed Apr 27 14:52:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11709 for ; Wed, 27 Apr 2005 14:52:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RIiFvS067450; Wed, 27 Apr 2005 11:44:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RIiFuT067449; Wed, 27 Apr 2005 11:44:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RIiDIw067431 for ; Wed, 27 Apr 2005 11:44:14 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so716605wra for ; Wed, 27 Apr 2005 11:44:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h5gOH8ZjPxfMTcBkRFukgUpcv3GIpq0AeQwKIMf1SWI4gj0AOq4etfYI/POVnH9Z1GtW7B6lWYdkQazD+pbAg5tsHKcXScL8H12KTKYlGfqRw8y/6q70cg9qpeDpoTVhibfm3COmmYS/9sU9ebScj3h34XyjcTB4EdVrIR00Q9U= Received: by 10.54.79.8 with SMTP id c8mr683583wrb; Wed, 27 Apr 2005 11:44:08 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Wed, 27 Apr 2005 11:44:08 -0700 (PDT) Message-ID: <68fba5c5050427114462c13b14@mail.gmail.com> Date: Wed, 27 Apr 2005 14:44:08 -0400 From: Robert Sayre Reply-To: Robert Sayre To: bob@wyman.us Subject: Re: PubSub CAN NOT support Atom with existing "no duplicate id" constraint Cc: Graham , atom-syntax In-Reply-To: <200504271828.DAO85414@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <200504271828.DAO85414@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3RIiEIw067436 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/27/05, Bob Wyman wrote: > In the absence of evidence that the proposed change will result in > damage or interoperability problems, I think the spec must change. A > security note is not sufficient. OK, we have two errors to balance here. One of them is the text we currently have, which creates problems for republishers. The other is detailed in Sam's "Clone Wars" post: http://www.intertwingly.net/blog/2005/04/09/Clone-Wars We could go with Graham's suggestion. We could also rework the inheritance/considered-to-apply/attribution text more generally, to include atom:source more explicitly. Is there anything else we can do that would license the validator to flag the Yahoo feed in Sam's post, but give PubSub et al. a little more room to breath? Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 27 14:52:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11713 for ; Wed, 27 Apr 2005 14:52:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RIiVpv067493; Wed, 27 Apr 2005 11:44:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RIiVOY067492; Wed, 27 Apr 2005 11:44:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf01.sitadelle.com [212.94.174.80]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RIiUqF067473 for ; Wed, 27 Apr 2005 11:44:30 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.35.80]) by smtp.cegetel.net (Postfix) with ESMTP id 81DE231806F; Wed, 27 Apr 2005 20:44:24 +0200 (CEST) Message-ID: <426FDD88.6090507@cegetel.net> Date: Wed, 27 Apr 2005 20:44:24 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Henry Story Cc: "'atom-syntax Syntax''" , Bob Wyman Subject: Re: PubSub CAN NOT support Atom with existing "no duplicate id" constraint References: <200504271548.DAO13916@ms8.netsolmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: > I think we should vote on the two solutions: > > A- the compromise solution you propose > B- the simple solution which simply allows entries with duplicate ids > C- No change > > My preference is clearly B then A, and certainly not C. Same for me. > As far as I am concerned there is no interop purpose for C (the current > limitation). Therefore it should be dropped. should or must? -- Thomas Broyer From owner-atom-syntax@mail.imc.org Wed Apr 27 15:03:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12789 for ; Wed, 27 Apr 2005 15:03:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RItZlj069141; Wed, 27 Apr 2005 11:55:35 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RItZta069140; Wed, 27 Apr 2005 11:55:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RItY1a069121 for ; Wed, 27 Apr 2005 11:55:35 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.35.80]) by smtp.cegetel.net (Postfix) with ESMTP id 1387922C143; Wed, 27 Apr 2005 20:55:29 +0200 (CEST) Message-ID: <426FE01F.4070501@cegetel.net> Date: Wed, 27 Apr 2005 20:55:27 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Walter Underwood Cc: atom-syntax Syntax Subject: Re: PaceOptionalSummary References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <20050427000243.GB7998@klangraum> <2641A798B3AF6C7DF64C5639@diva.verity.com> In-Reply-To: <2641A798B3AF6C7DF64C5639@diva.verity.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > I'm not being entirely silly here. We could distinguish between > "I am not providing a summary" (no element) and "the summary is void" > (empty summary). +1 This means I agree with Rob that these [1] three entries mean different things. [1] http://www.imc.org/atom-syntax/mail-archive/msg14432.html -- Thomas Broyer From owner-atom-syntax@mail.imc.org Wed Apr 27 15:30:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16068 for ; Wed, 27 Apr 2005 15:30:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RJMdpK073153; Wed, 27 Apr 2005 12:22:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RJMdiJ073152; Wed, 27 Apr 2005 12:22:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RJMck5073146 for ; Wed, 27 Apr 2005 12:22:39 -0700 (PDT) (envelope-from brett.lindsley@labs.mot.com) Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j3RJW1Bo026542; Wed, 27 Apr 2005 12:32:05 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j3RJORgs001504; Wed, 27 Apr 2005 14:24:27 -0500 (CDT) Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j3RJMWVp015907; Wed, 27 Apr 2005 14:22:32 -0500 (CDT) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0IFM00AYIDTK5Y@ims1.labs.mot.com>; Wed, 27 Apr 2005 14:22:32 -0500 (CDT) Date: Wed, 27 Apr 2005 14:22:32 -0500 From: Brett Lindsley Subject: Re: PaceOptionalSummary To: Antone Roundy Cc: atom-syntax@imc.org Message-id: <426FE678.9040800@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT This gets back to the brief discussion I had with Henry Story about the attributes of the link vs the attributes of what the link points to. A single resource (theoretically) exists but there may be various representations of it. How do we specifiy this with the current link model? My initial thoughts with respect to enclosures is a single resource (e.g. an image) but it may have various representations (e.g. resolutions, etc.). We could have a single "alternate" link (link attribute) but several URLs, each with its own attributes (minimal, authoritative, etc.). But I don't want to reopen this issue... Brett Lindsley, Motorola Labs Antone Roundy wrote: > > On Wednesday, April 27, 2005, at 08:53 AM, Eric Scheid wrote: > >> why not >> >> >> >> >> >> ... >> >> >> and the client agent can then present these to the user to select from. > > > At present: > > atom:feed elements MUST NOT contain more than one atom:link > element with a rel attribute value of "alternate" that has the > same type attribute value. > > ...but if that were something other than "alternate"... > > The question is, do you want this to be automatically discoverable or > only user selectable? Finding the authoritative variant automatically > might be important for some applications. Finding a variant with a > specific set of elements and as few others as possible might be > important for other applications. That COULD be done by downloading > and inspecting each variant. > > ...but I'm really speculating here. The main reason I brought this up > now was because, given that some people are already publishing variant > feeds, it might be good to answer the question of whether using the > same atom:id in variants of an entry is legal, and if so, how such > things should/could be handled. > From owner-atom-syntax@mail.imc.org Wed Apr 27 15:41:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17939 for ; Wed, 27 Apr 2005 15:41:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RJToeq074172; Wed, 27 Apr 2005 12:29:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RJToOq074171; Wed, 27 Apr 2005 12:29:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ussjmh01.bea.com (ussjmh01.bea.com [63.96.162.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RJTnAh074157; Wed, 27 Apr 2005 12:29:49 -0700 (PDT) (envelope-from markn@bea.com) Received: from ussjfe02.amer.bea.com (ussjfe02.bea.com [172.16.120.52]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id j3RJTm4w029447; Wed, 27 Apr 2005 12:29:48 -0700 Received: from USSFEX01.amer.bea.com ([10.32.0.56]) by ussjfe02.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 27 Apr 2005 12:29:48 -0700 Received: from [172.16.1.5] ([172.24.28.199]) by USSFEX01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 27 Apr 2005 12:29:47 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6ee36f0803ca606a702cc980dcad01f3@bea.com> Content-Transfer-Encoding: 7bit Cc: Atom WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: On SHOULD, MUST, and semantics Date: Wed, 27 Apr 2005 11:37:54 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 27 Apr 2005 19:29:48.0096 (UTC) FILETIME=[796B0400:01C54B5F] X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.4.27.9 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Well said, Paul; this articulates the reasons for a profiling mechanism much more effectively than I ever did. Cheers, On Apr 27, 2005, at 9:28 AM, Paul Hoffman wrote: > > A few brief notes for the WG to chew on. > > - Literal interpretation of 2119 for a document format such as Atom > would make nearly every element of an entry a MAY. It is a tad > dishonest to say "why is element Xyz even a SHOULD?" when we have a > *long* list of MUSTs already. It is no wonder that people are changing > their opinion of any particular element from MUST to MAY to SHOULD and > around again. > > - The format document, like many IETF Applications Area specs, is > steeped in hidden semantics. If I suggested that atom:title go from > MUST to MAY, there would be outrage. The reason is that most of us > think of entries as having some semantics that include a title. We > don't say in the format document why we made atom:title a MUST: it's > just "obvious". > > - Differentiating the importance of the semantics of various elements > is really, really hard, and people's opinions change over time. I > strongly suspect that many of the less-vocal-but-still-active members > of this list have changed their view of the importance of > atom:category at least once. This is the hardest one to align with > making a simple-to implement spec. The fewer cross-element links we > have, the easier it will be for an implementer. > > - We have, unfortunately, linked the semantics of two or more elements > together. atom:content and atom:summary are linked because of their > semantics (if you don't have a readable content, you MUST/SHOULD/MAY > have a summary). > > - We have, fortunately, not required linked semantics for extensions. > If I came out with hoffman:content-plus-plus, I can't assume that > whatever linkage there is between atom:summary and atom:content will > apply to my extension. But, of course, if someone considers > hoffman:content-plus-plus to be like atom:content, they may *want* the > same linkages. > > - Every SHOULD, by definition, adds logic into the software that > creates a message in the spec'd format. In the long history of the > IETF, this also tends to prevent interop, because it gives two > differing parties a soapbox to argue from. > > - Person A may think that an optional element that is missing means W. > Person B may think that an optional element that is present but null > means X. Person C may think that W == X, Person D may think that W != > X. Person C and Person D will probably code very differently. > > Proposal for thinking about: to simplify the spec, "atom:summary" > should either be a MUST in all cases or a MAY in all cases. If it is > just semantic like "atom:category", it should be a MAY. If it is > inherently valuable like "atom:title", it should be a MUST. > > --Paul Hoffman, Director > --Internet Mail Consortium > > > -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems From owner-atom-syntax@mail.imc.org Wed Apr 27 16:07:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23864 for ; Wed, 27 Apr 2005 16:07:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RJxB5C078542; Wed, 27 Apr 2005 12:59:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RJxBE1078541; Wed, 27 Apr 2005 12:59:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RJx9lb078515 for ; Wed, 27 Apr 2005 12:59:10 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.35.80]) by smtp.cegetel.net (Postfix) with ESMTP id D815F22C0E0; Wed, 27 Apr 2005 21:59:03 +0200 (CEST) Message-ID: <426FEF0B.60405@cegetel.net> Date: Wed, 27 Apr 2005 21:59:07 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Antone Roundy Cc: atom-syntax@imc.org Subject: Re: PaceOptionalSummary References: <248F228C-B726-11D9-9B37-003065EA6144@geckotribe.com> In-Reply-To: <248F228C-B726-11D9-9B37-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > On Wednesday, April 27, 2005, at 04:21 AM, Brett Lindsley wrote: > >> One reason for title only feeds is to address bandwidth limited >> devices. The server I set up provides the same feed in two >> different formats - one title only and the other with >> title/summary/etc. The end client can decide which feed it wants to >> work with based on its capabilities; > > This raises a few questions: > > 1) How does one indicate the existence of variants? link@rel="alternate" or using a custom (read: extension) relations or using extension elements. See also my comments below on 3). > 2) Can/should the > variant feeds use the same atom:ids for variants of the same > entries? Yes, IMO, as they identify the same entry, with different, more or less rich, representations. However, does the current draft explicitly say that or can it be understood that different representations of the same entry must/should/may have different ids? This reminds me of link@rel="alternate" vs. link@rel="alternate-of" discussion... > 3) How does a client select a preferred variant? Good question, but it seems to me that it's beyond the scope of the current (format) spec. It should IMO go with autodiscovery. > 4) How does > an aggregator discover the "complete" and/or "authoritative" variant > of an entry? Autodiscovery? IMO, all this should be recorded and discussed later when the autodiscovery spec will be on air. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Wed Apr 27 16:19:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28473 for ; Wed, 27 Apr 2005 16:19:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RKE98s080857; Wed, 27 Apr 2005 13:14:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RKE9WZ080856; Wed, 27 Apr 2005 13:14:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RKE8t9080842 for ; Wed, 27 Apr 2005 13:14:08 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] ([66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3RKHxbe025232; Wed, 27 Apr 2005 16:17:59 -0400 Message-ID: <426FF269.2030302@intertwingly.net> Date: Wed, 27 Apr 2005 16:13:29 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Tim Bray , Atom WG Subject: Re: On SHOULD, MUST, and semantics References: <426FC2A3.6000108@intertwingly.net> <68fba5c50504271003b63ab2d@mail.gmail.com> In-Reply-To: <68fba5c50504271003b63ab2d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > On 4/27/05, Sam Ruby wrote: > >>Actually, that's one of the key reasons why I like the MUST for summary. >> If somebody invents a popular hoffman:content-plus-plus, then feeds >>that include it lieu of atom:content will need to include a human >>readable summary that can be used by existing clients. > > If they nest a content-plus-plus inside atom:content, they wouldn't > have to include that summary, right? My recollection of the consensus of the decision to nuke PaceNukeMultipart apparently is flawed, as I can't find any email discussion that backs up what I seem to remember. Judging by the text in rationale listed in PaceOptionalSummary, I gather that the author of that Pace came to a similar conclusion. Simply put: my recollection was that we were successful in killing PaceNukeMultipart with the argument that every entry would have some displayable text (either plain, html, or xhtml). That's pretty much orthogonal to the discussion we are having here (i.e., if an entry does not have any summary or content, then it doesn't discriminate - it is equally as inaccessible to everybody); but if that was the actual intent of the consensus, then the document should be updated to reflect that. Furthermore, it would rule out the tunneling of hoffman:content-plus-plus as a dodge to avoid providing a summary that could be understood by existing clients. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Apr 27 17:03:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06744 for ; Wed, 27 Apr 2005 17:03:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RKswdm086308; Wed, 27 Apr 2005 13:54:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RKswSH086307; Wed, 27 Apr 2005 13:54:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-110-244.cruzio.com [63.249.110.244]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RKst3a086293; Wed, 27 Apr 2005 13:54:57 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 27 Apr 2005 13:54:54 -0700 To: Graham From: Paul Hoffman Subject: Re: On SHOULD, MUST, and semantics Cc: atom-syntax Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 6:47 PM +0100 4/27/05, Graham wrote: >On 27 Apr 2005, at 5:28 pm, Paul Hoffman wrote: > >>Proposal for thinking about: to simplify the spec, "atom:summary" >>should either be a MUST in all cases or a MAY in all cases. If it >>is just semantic like "atom:category", it should be a MAY. If it is >>inherently valuable like "atom:title", it should be a MUST. > >What isn't "inherently valuable" about a "semantic". False >dichotomy. What a load of unconstructive bollocks. False reading. I was comparing "just semantic" to "inherently valuable". Both atom:category and atom:title are obviously both semantic, yes? --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Apr 27 17:49:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10958 for ; Wed, 27 Apr 2005 17:49:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RLW60E090988; Wed, 27 Apr 2005 14:32:06 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RLW6Uo090987; Wed, 27 Apr 2005 14:32:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RLW3Mm090964 for ; Wed, 27 Apr 2005 14:32:05 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so817178wra for ; Wed, 27 Apr 2005 14:31:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JBMYLFxRTGRk0CyndOmz8oE+tDjLGe4OePts9vCDnWikRamkgUuYrGqHaE9w/B7nBRrLvxbB+0eeMJovAGCsOMnuUCBX8B8a7LnfnZTcxjt1Abn7efKTr+mPr+lvbhg2rgP4iiGLR3wGnWIBCNVK8kywgKbzaxunnzmDQpYKsFQ= Received: by 10.54.15.6 with SMTP id 6mr755593wro; Wed, 27 Apr 2005 14:31:55 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Wed, 27 Apr 2005 14:31:55 -0700 (PDT) Message-ID: <68fba5c505042714312eeb0a58@mail.gmail.com> Date: Wed, 27 Apr 2005 17:31:55 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: On SHOULD, MUST, and semantics Cc: Tim Bray , Atom WG In-Reply-To: <426FF269.2030302@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426FC2A3.6000108@intertwingly.net> <68fba5c50504271003b63ab2d@mail.gmail.com> <426FF269.2030302@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3RLW5Mm090980 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/27/05, Sam Ruby wrote: > Robert Sayre wrote: > > On 4/27/05, Sam Ruby wrote: > > > >>Actually, that's one of the key reasons why I like the MUST for summary. > >> If somebody invents a popular hoffman:content-plus-plus, then feeds > >>that include it lieu of atom:content will need to include a human > >>readable summary that can be used by existing clients. > > > > If they nest a content-plus-plus inside atom:content, they wouldn't > > have to include that summary, right? > Simply put: my recollection was that we were successful in killing > PaceNukeMultipart with the argument that every entry would have some > displayable text (either plain, html, or xhtml). My recollection is that we were successful in removing multipart content because references to linked alternates would have sufficient granularity to provide accessible alternatives. If there were multiple content elements, an entry would need to provide references for each of those elements, and start to look like a feed itself. I don't lend much weight to either of our recollections, though. Those discussions were disorganized, rude, and full of intimidation. > That's pretty much orthogonal to the discussion we are having here > (i.e., if an entry does not have any summary or content, then it doesn't > discriminate - it is equally as inaccessible to everybody); My opinion is that ~10 WG members are currently clearly stating their belief that summary/content are optional. > but if that > was the actual intent of the consensus, then the document should be > updated to reflect that. If you are suggesting that the format should require a summary for more non-empty types of content than it currently does, I don't have an objection to that, but we'll have to see a Pace. > Furthermore, it would rule out the tunneling > of hoffman:content-plus-plus as a dodge to avoid providing a summary > that could be understood by existing clients. I don't think we can defend ourselves from bad-faith publishers. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 27 18:46:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16499 for ; Wed, 27 Apr 2005 18:46:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RMdKGB099228; Wed, 27 Apr 2005 15:39:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RMdKLF099227; Wed, 27 Apr 2005 15:39:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.usask.ca (mail.usask.ca [128.233.192.250]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RMdJwN099221 for ; Wed, 27 Apr 2005 15:39:20 -0700 (PDT) (envelope-from ans208@mail.usask.ca) Received: from conversion-daemon.mail.usask.ca by mail.usask.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0IFM00701MTQLR@mail.usask.ca> (original mail from ans208@mail.usask.ca) for atom-syntax@imc.org; Wed, 27 Apr 2005 16:39:18 -0600 (CST) Received: from [128.233.153.95] (ascl-g2-5.usask.ca [128.233.153.95]) by mail.usask.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0IFM00LXSMXE2J@mail.usask.ca> for atom-syntax@imc.org; Wed, 27 Apr 2005 16:39:18 -0600 (CST) Date: Wed, 27 Apr 2005 16:39:15 -0600 From: Andreas Sewe Subject: Re: PaceOptionalSummary In-reply-to: <426FEF0B.60405@cegetel.net> To: atom-syntax@imc.org Message-id: <42701493.9020503@mail.usask.ca> Organization: Student, University of Saskatchewan MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: de-de, de-at, de-ch, de, en-gb, en-ca, en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 References: <248F228C-B726-11D9-9B37-003065EA6144@geckotribe.com> <426FEF0B.60405@cegetel.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Thomas Broyer wrote: > Antone Roundy wrote: >> This raises a few questions: >> >> 1) How does one indicate the existence of variants? > > link@rel="alternate" or using a custom (read: extension) > relations or using extension elements. See also my comments > below on 3). I'll just stop lurking for a minute to make the following suggestion: Why do you not simply follow the lead of HTML [1] on this issue, which uses a list of values--to express, e.g., link@rel= "alternate stylesheet"? So maybe something along the lines of link@rel="alternate summary" could work for Atom, too. Regards, Andreas [1] From owner-atom-syntax@mail.imc.org Wed Apr 27 19:23:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18781 for ; Wed, 27 Apr 2005 19:23:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RNCkT6001785; Wed, 27 Apr 2005 16:12:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RNCkPd001782; Wed, 27 Apr 2005 16:12:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RNChpd001774 for ; Wed, 27 Apr 2005 16:12:43 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3RNBfik015131; Thu, 28 Apr 2005 00:11:46 +0100 (BST) In-Reply-To: <68fba5c505042714312eeb0a58@mail.gmail.com> References: <426FC2A3.6000108@intertwingly.net> <68fba5c50504271003b63ab2d@mail.gmail.com> <426FF269.2030302@intertwingly.net> <68fba5c505042714312eeb0a58@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: On SHOULD, MUST, and semantics Date: Thu, 28 Apr 2005 00:11:39 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27 Apr 2005, at 10:31 pm, Robert Sayre wrote: > My opinion is that ~10 WG members are currently clearly stating their > belief that summary/content are optional. You should make clear that most of those people supported a misleading Pace that didn't clearly state its side-effects beyond making feeds-where-no-title-is-available legal. Whether or not they support the general position that "summary/content are optional" is not for you to make. Graham From owner-atom-syntax@mail.imc.org Wed Apr 27 20:59:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26343 for ; Wed, 27 Apr 2005 20:59:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S0pfFL006950; Wed, 27 Apr 2005 17:51:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3S0pf4f006949; Wed, 27 Apr 2005 17:51:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S0pejM006936 for ; Wed, 27 Apr 2005 17:51:41 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3S0oo79005543; Thu, 28 Apr 2005 01:50:56 +0100 (BST) In-Reply-To: <68fba5c505042717412647913f@mail.gmail.com> References: <426FC2A3.6000108@intertwingly.net> <68fba5c50504271003b63ab2d@mail.gmail.com> <426FF269.2030302@intertwingly.net> <68fba5c505042714312eeb0a58@mail.gmail.com> <68fba5c505042717412647913f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Subject: Re: On SHOULD, MUST, and semantics Date: Thu, 28 Apr 2005 01:50:48 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 28 Apr 2005, at 1:41 am, Robert Sayre wrote: > Sorry Graham, my conclusion is perfectly reasonable. It fucking is not. The people +1ed a specific Pace with a particular purpose. Arguing that you therefore have support for a general position is totally disingenuous. Also, you may not be the most impartial judge of the reasonableness of your position, unless there's two of you. Graham From owner-atom-syntax@mail.imc.org Wed Apr 27 21:07:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26854 for ; Wed, 27 Apr 2005 21:07:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S0wMvN007243; Wed, 27 Apr 2005 17:58:22 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3S0wMQn007242; Wed, 27 Apr 2005 17:58:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S0wJft007232 for ; Wed, 27 Apr 2005 17:58:21 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so908195wra for ; Wed, 27 Apr 2005 17:58:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aWwgesOt5usAStT0L8gPX/hGierzX8D5riGszwEw1EOnJRQVhP3uB1TRTWaN80oGiUUvvL+zjj/ggviCQQJkhufsA0/Q6nvskLuDuBO/qkVHKdoF6dFSStu2uYGb8V22yJXtLonmLa3/bWx+aAsWPyEN0ES1MW/GkwaTntROHw4= Received: by 10.54.78.16 with SMTP id a16mr839712wrb; Wed, 27 Apr 2005 17:58:12 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Wed, 27 Apr 2005 17:58:12 -0700 (PDT) Message-ID: <68fba5c5050427175817770589@mail.gmail.com> Date: Wed, 27 Apr 2005 20:58:12 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Graham Subject: Re: On SHOULD, MUST, and semantics Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426FC2A3.6000108@intertwingly.net> <68fba5c50504271003b63ab2d@mail.gmail.com> <426FF269.2030302@intertwingly.net> <68fba5c505042714312eeb0a58@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3S0wMft007237 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/27/05, Graham wrote: > On 27 Apr 2005, at 10:31 pm, Robert Sayre wrote: > > > My opinion is that ~10 WG members are currently clearly stating their > > belief that summary/content are optional. > > You should make clear that most of those people supported a misleading > Pace that didn't clearly state its side-effects beyond making > feeds-where-no-title-is-available legal. Whether or not they support > the general position that "summary/content are optional" is not for you > to make. On 4/27/05, Graham wrote: > On 28 Apr 2005, at 1:41 am, Robert Sayre wrote: > > > Sorry Graham, my conclusion is perfectly reasonable. > > It fucking is not. The people +1ed a specific Pace with a particular > purpose. Arguing that you therefore have support for a general position > is totally disingenuous. Well, Graham, all we can really talk about is what the Pace says. It's fairly clear. The fact that those opposing it didn't take the time to read it or the spec is not my problem, nor does it indicate disingenuousness of any sort on my part. If someone were looking for that, they could go back through the archives and look at the arguments of the 2 or 3 people that seem to want this argument to continue. They keep changing, don't they? Those 2 or 3 people are lucky that I pointed out they might want to close the front door before they put their tinfoil hats on. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Apr 27 22:32:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02160 for ; Wed, 27 Apr 2005 22:32:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RIlSnD067920; Wed, 27 Apr 2005 11:47:28 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RIlSPJ067919; Wed, 27 Apr 2005 11:47:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.pubsub.com (mail.pubsub.com [209.11.36.150]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RIlSl9067909 for ; Wed, 27 Apr 2005 11:47:28 -0700 (PDT) (envelope-from bobwyman@pubsub.com) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by mail.pubsub.com (Postfix) with ESMTP id 9F6A572413F; Wed, 27 Apr 2005 14:47:22 -0400 (EDT) Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: PubSub CAN NOT support Atom with existing "no duplicate id" constraint Date: Wed, 27 Apr 2005 14:47:18 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVLVUMZrqxPXh++SDmY1sfQRFBwvgAAbAQQ In-Reply-To: Message-Id: <20050427184722.9F6A572413F@mail.pubsub.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > If PubSub is subscribed to the feed pointed to by > atom:source[@rel='self'], then can't you simply drop any entries > claiming to be from that feed but found at a different URI? You'll be > getting those entries from the source if they're legitimate, so is > there any reason to accept them from elsewhere? Or are you keeping > them in case they contain additional information added by someone else? Certainly, the content of an entry might be different depending on its source. PubSub, for instance, now adds what we consider to be important information to entries and we'll be doing more of that in the future. But, that's only one of the reasons for concern here. The mere fact that an entry has been published in a secondary feed is, in some cases, important information and in some cases, we should be delivering up content which in other situations would be filtered out as duplicative. Consider something like Scoble's well-known "LinkBlog" which contains copies of things that he has found to be interesting when reading through blogs. If we followed the policy of discarding everything that was sourced somewhere outside the LinkBlog itself, we would never deliver any content to anyone who subscribed explicitly to receive data from Scoble's LinkBlog... (i.e. A PubSub weblog subscription such as: "SOURCE:www.scobleizer.com/linkblog" ) What we are considering doing to handle things like link blogs and other cases where copied entries are found is flagging items as "duplicates" when we discover them and then attaching a default "no-duplicates" predicate on all normal subscriptions. However, subscriptions that included "SOURCE:" predicates would have an "allow duplicates" predicate attached to them. (Yes, users could override this.) This means that you wouldn't get duplicates with a general subscription, however, you *would* receive content that we would normally filter out -- if you subscribed to a specific feed. Internally, this means that we would process all new or changed entries that we find in any feed, but whether or not a duplicate is delivered to the user depends on the users' subscription. Does this sound complicated? Well, it is... But, providing an intermediary like we do just isn't quite as simple as building a desktop aggregator. There are a number of other similar situations that are problematic. bob wyman From owner-atom-syntax@mail.imc.org Wed Apr 27 22:42:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03012 for ; Wed, 27 Apr 2005 22:42:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S2Wqgn013218; Wed, 27 Apr 2005 19:32:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3S2Wq0d013217; Wed, 27 Apr 2005 19:32:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S2WqkK013209 for ; Wed, 27 Apr 2005 19:32:52 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc12) with SMTP id <2005042802324601200dc1hve>; Thu, 28 Apr 2005 02:32:46 +0000 Date: Wed, 27 Apr 2005 20:32:45 -0600 Subject: Re: On SHOULD, MUST, and semantics Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, April 27, 2005, at 05:11 PM, Graham wrote: > On 27 Apr 2005, at 10:31 pm, Robert Sayre wrote: >> My opinion is that ~10 WG members are currently clearly stating their >> belief that summary/content are optional. > > You should make clear that most of those people supported a misleading > Pace that didn't clearly state its side-effects beyond making > feeds-where-no-title-is-available legal. Whether or not they support > the general position that "summary/content are optional" is not for > you to make. > I didn't find the Pace misleading, and support the position that summary/content are optional. On Wednesday, April 27, 2005, at 10:49 AM, Sam Ruby wrote: > Paul Hoffman wrote: >> - We have, unfortunately, linked the semantics of two or more >> elements together. atom:content and atom:summary are linked because >> of their semantics (if you don't have a readable content, you >> MUST/SHOULD/MAY have a summary). >> - We have, fortunately, not required linked semantics for extensions. >> If I came out with hoffman:content-plus-plus, I can't assume that >> whatever linkage there is between atom:summary and atom:content will >> apply to my extension. But, of course, if someone considers >> hoffman:content-plus-plus to be like atom:content, they may *want* >> the same linkages. > > Actually, that's one of the key reasons why I like the MUST for > summary. If somebody invents a popular hoffman:content-plus-plus, > then feeds that include it lieu of atom:content will need to include a > human readable summary that can be used by existing clients. > This is definitely the most convincing argument I've heard for requiring the summary. But it doesn't make it a MUST for me. If hoffman:content-plus-plus gets popular enough for this to matter, and publishers publish a feed with that element, no atom:content, and no atom:summary, and don't publish a variant with one or both of those, then either we've really missed the boat with this spec or Paul has invented something so revolutionary and great that old apps deserve to be obsolete and unsupported. I think this goes just a little beyond the limits of what we need to foresee and ensure we're ready for. I know it wouldn't be enforcable, but in some imaginary world, the bullet point that PaceOptionalSummary proposes removing could be replace by "the atom:entry element contains no atom:content element, but does contain an extension element that carries the content of the entry". I wouldn't be opposed to that. But back to the real world... On Wednesday, April 27, 2005, at 04:35 AM, Sam Ruby wrote: > So.. can we agree on SHOULD? > I could live with it SHOULD or MAY. From owner-atom-syntax@mail.imc.org Thu Apr 28 00:54:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14893 for ; Thu, 28 Apr 2005 00:54:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S4jVP8022940; Wed, 27 Apr 2005 21:45:31 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3S4jVnW022939; Wed, 27 Apr 2005 21:45:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S4jUei022922 for ; Wed, 27 Apr 2005 21:45:30 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1088396wri for ; Wed, 27 Apr 2005 21:45:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RJIYgVgt8rW5hg+IGgNS47MJwWjbMb1bA77SbQPhyzqvUbf9Rqpsak2b6dse5+M3C1hz/4gOkA8oijgmKunckN2FHX/+OA0yg/2TKAa+NAVe68fjOKR1pb/idoh+9+th8k0KYNH824cDZbPJPBqcfQFtoDajwn5G3yKj1VnXVfc= Received: by 10.54.125.20 with SMTP id x20mr550913wrc; Wed, 27 Apr 2005 21:45:24 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Wed, 27 Apr 2005 21:45:24 -0700 (PDT) Message-ID: <540e37320504272145dc0dd8c@mail.gmail.com> Date: Wed, 27 Apr 2005 23:45:24 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax Subject: Re: PaceOptionalSummary In-Reply-To: <68fba5c505042707387c289d87@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> <426EF42C.5010505@intertwingly.net> <68fba5c505042619152ad7b5f6@mail.gmail.com> <426EFA35.8010103@intertwingly.net> <68fba5c505042707387c289d87@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3S4jUei022934 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Do you have an example? Robert: I'm an example. I also drop title-free feeds (see Scripting News)... given the nature of the app, a feed without titles or content is just worthless. That doesn't mean I have anything against content-free feeds for specific applications. After all, as you pointed out, I produce some. In fact, that's why I'm pro-SHOULD in this case; a weblog or wiki feed (Atom's two primary targets) should contain some form of content. But if you know what you're doing, and have no other choice, then drop it and cross your fingers. > What are the interoperability considerations that must be carefully > weighed? Apps that expect content won't get any. I haven't checked things out in a while, but once upon a time, Newsgator-in-Outlook would use the item's link as the content for a content-free feed. Newzcrawler, meanwhile, automatically forwards the user (via the integrated browser) to the link. And as I've already mentioned, I'll drop the items entirely. The publisher will therefore face unpredictable results relating to a key part of aggregator functionality... that's definitely worthy of a SHOULD. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Thu Apr 28 01:54:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18203 for ; Thu, 28 Apr 2005 01:54:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S5dDJU040722; Wed, 27 Apr 2005 22:39:13 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3S5dDoV040721; Wed, 27 Apr 2005 22:39:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S5dBg3040643 for ; Wed, 27 Apr 2005 22:39:11 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1009884wra for ; Wed, 27 Apr 2005 22:39:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZyNnaDPmieSNwwSvtv32rQD2GMqkzlM+NQS9w3GpPtdSlzsC9SLau2Yql6V5k/smjBVrL2wAMezepsIYlOi0gBzeF/vIgjMT6+26NgV9hOXKERBMGhG8GI6ylZUbRi4VdbErjYjr8zyW6cd1too8QP9re8zFjJlU6gKzvn4cFSA= Received: by 10.54.121.12 with SMTP id t12mr568525wrc; Wed, 27 Apr 2005 22:39:05 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Wed, 27 Apr 2005 22:39:05 -0700 (PDT) Message-ID: <68fba5c505042722395e8c66a@mail.gmail.com> Date: Thu, 28 Apr 2005 01:39:05 -0400 From: Robert Sayre Reply-To: Robert Sayre To: "Roger B." Subject: Re: PaceOptionalSummary Cc: atom-syntax In-Reply-To: <540e37320504272145dc0dd8c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> <426EF42C.5010505@intertwingly.net> <68fba5c505042619152ad7b5f6@mail.gmail.com> <426EFA35.8010103@intertwingly.net> <68fba5c505042707387c289d87@mail.gmail.com> <540e37320504272145dc0dd8c@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3S5dCg3040714 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/28/05, Roger B. wrote: > > > Do you have an example? > > Robert: I'm an example. I also drop title-free feeds (see Scripting > News)... given the nature of the app, a feed without titles or content > is just worthless. That's fine, but we're not here to tailor the format to your app. I've gotten feedback from embedded device developers complaining that XHTML requires them to do more parsing than their app can handle, for little practical benefit (for them). Note that we're also giving them the short end of the stick with this requirement. > That doesn't mean I have anything against content-free feeds for > specific applications. After all, as you pointed out, I produce some. > In fact, that's why I'm pro-SHOULD in this case; a weblog or wiki feed > (Atom's two primary targets) should contain some form of content. This is the assertion I have a problem with, and the opinions expressed by others echo my gripe. > But > if you know what you're doing, and have no other choice, then drop it > and cross your fingers. Well, now we're just back to the sorts of feeds that are supposedly perfectly ok on the condition that they contain an empty summary element. We seem to be forgetting that RSS feeds were initially for headlines and links alone. It's obvious that full-content feeds are much more popular now, but there is no definition of "syndication" or "RSS" in common use that precludes title-only feeds. > > What are the interoperability considerations that must be carefully > > weighed? > > Apps that expect content won't get any. I haven't checked things out > in a while, but once upon a time, Newsgator-in-Outlook would use the > item's link as the content for a content-free feed. Newzcrawler, > meanwhile, automatically forwards the user (via the integrated > browser) to the link. And as I've already mentioned, I'll drop the > items entirely. > > The publisher will therefore face unpredictable results relating to a > key part of aggregator functionality... that's definitely worthy of a > SHOULD. Publishers face unpredictable results in any case. We don't mandate that apps do anything with data they receive, so they are free to decide the summary is too short and showing the web page would be better (experiment with this in RSS Bandit). By default, Mozilla Thunderbird doesn't show RSS summaries or Atom content when they are present. Instead it behaves as NewzCrawler does in all cases. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 28 03:12:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14999 for ; Thu, 28 Apr 2005 03:12:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S729Xv073482; Thu, 28 Apr 2005 00:02:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3S729Kn073481; Thu, 28 Apr 2005 00:02:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S7284h073473 for ; Thu, 28 Apr 2005 00:02:08 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j3S728i7023989 for ; Thu, 28 Apr 2005 01:02:08 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IFN00AZ1A7J9R@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 28 Apr 2005 01:02:08 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFN00HNOA7IJS@mail.sun.net> for atom-syntax@imc.org; Thu, 28 Apr 2005 01:02:07 -0600 (MDT) Date: Thu, 28 Apr 2005 00:03:01 -0700 From: Tim Bray Subject: Cleanup phase In-reply-to: <426FB837.8050905@intertwingly.net> To: "'atom-syntax Syntax''" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200504271548.DAO13916@ms8.netsolmail.com> <426FB837.8050905@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Apr 27, 2005, at 9:05 AM, Sam Ruby wrote (about the proposal to address Bob Wyman's dupes issue): > It would help if a Pace could be written. Funny you should say that, Sam. We have another week or so to go on our IETF Last Call, but the volume of input is low enough that Paul & I think we can safely start doing our own internal-issues final cleanup. We've been following the WG discourse as best I can, but the volume is high. Thus, we think that to be fair and transparent, we require a last round of Paces for any/all changes to the format-08 draft. Sam, perhaps you could have a scan at the current set of Paces and see if any other than PaceOptionalSummary are actually up-to-date and suitable for this last round? (I'd be surprised, but you never know). I think there are quite a few little things for which I've seen evidence of consensus on the mailing list, in fact I think Rob/Mark have pounced on a couple and they're in -08; but if you're behind one and it isn't, please Pace-i-fy it and let's get with the cleanup. LAST CHANCE, we mean it. And of course we're going to have to fish some sort of consensus out of this horrid summary-required mess. -Tim From owner-atom-syntax@mail.imc.org Thu Apr 28 03:31:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16624 for ; Thu, 28 Apr 2005 03:31:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S7NjpW083329; Thu, 28 Apr 2005 00:23:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3S7NjI3083328; Thu, 28 Apr 2005 00:23:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S7Nfm9083268 for ; Thu, 28 Apr 2005 00:23:43 -0700 (PDT) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 28 Apr 2005 12:21:01 +1000 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 28 Apr 2005 17:00:15 +1000 Subject: Re: PaceOptionalSummary From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <540e37320504272145dc0dd8c@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 28/4/05 2:45 PM, "Roger B." wrote: >> Do you have an example? > > Robert: I'm an example. I also drop title-free feeds (see Scripting > News)... given the nature of the app, a feed without titles or content > is just worthless. I'm also an example - if I discover that a feed I once loved for it's tech content is now given over to endless cat pictures, or discussion of politics, then I too will drop that feed post haste. Even if it does have a summary. Sorry, what was your point again? e. From owner-atom-syntax@mail.imc.org Thu Apr 28 04:07:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19803 for ; Thu, 28 Apr 2005 04:07:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S7sA5O096761; Thu, 28 Apr 2005 00:54:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3S7sAR9096760; Thu, 28 Apr 2005 00:54:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S7s9pe096746 for ; Thu, 28 Apr 2005 00:54:09 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3S5wBPR005935; Thu, 28 Apr 2005 01:58:15 -0400 Message-ID: <42709698.1080705@intertwingly.net> Date: Thu, 28 Apr 2005 03:54:00 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax Subject: Re: PaceOptionalSummary References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> <426EF42C.5010505@intertwingly.net> <68fba5c505042619152ad7b5f6@mail.gmail.com> <426EFA35.8010103@intertwingly.net> <68fba5c505042707387c289d87@mail.gmail.com> <540e37320504272145dc0dd8c@mail.gmail.com> <68fba5c505042722395e8c66a@mail.gmail.com> In-Reply-To: <68fba5c505042722395e8c66a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > On 4/28/05, Roger B. wrote: > >>>Do you have an example? >> >>Robert: I'm an example. I also drop title-free feeds (see Scripting >>News)... given the nature of the app, a feed without titles or content >>is just worthless. > > That's fine, but we're not here to tailor the format to your app. Robert: why did you ask for an example? - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Apr 28 04:17:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22543 for ; Thu, 28 Apr 2005 04:17:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S8A9X5002986; Thu, 28 Apr 2005 01:10:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3S8A9OL002985; Thu, 28 Apr 2005 01:10:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S8A6ME002938 for ; Thu, 28 Apr 2005 01:10:08 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1056281wra for ; Thu, 28 Apr 2005 01:10:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ivEbC2Q170VemqIqHvzCqYLrhYq/En55FjN/Noh8Bu2jXY8K3TpAYEfGX26F9uOQsnbZxWWqYjPkIwBU6M1YI88ZR628M3M+6KWP9cbZpTO7k1/dFB9KNjJXk0dJTdHSBl9S2gqWzGX2b2GzTQnATobtDnUomAlDpIpf78H2dHs= Received: by 10.54.10.7 with SMTP id 7mr986055wrj; Thu, 28 Apr 2005 01:10:00 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 28 Apr 2005 01:10:00 -0700 (PDT) Message-ID: <68fba5c5050428011036f1021e@mail.gmail.com> Date: Thu, 28 Apr 2005 04:10:00 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray Subject: Re: Cleanup phase Cc: "atom-syntax Syntax'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <200504271548.DAO13916@ms8.netsolmail.com> <426FB837.8050905@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3S8A8ME002978 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/28/05, Tim Bray wrote: > And of course we're going to have to fish some > sort of consensus out of this horrid summary-required mess. That shouldn't be hard. I don't think the WG has ever been more decisive. If PaceOptionalSummary received 10 negative opinions, I'm quite sure the chairs would characterize it as "drowning in -1s". Are we "drowning in +1s" yet? Every bit of syndication code written since my.netscape.com in 1999 can deal with title-only feeds. There's your running code. The IETF process is designed get work done when a vocal minority of WG members makes a lot of noise about a given issue. In this case, the WG has let the minority present a series of arguments, and some of the arguments contradict previous ones. I think perhaps we've hit bottom. I'm pretty sure Graham just wrote that I couldn't use the 7-line PaceOptionalSummary, which made summaries and content optional by striking one line from the spec, to assert that the WG wanted to make summaries optional. This is so over, I can't believe it. I cannot believe we are entertaining this tripe. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 28 04:26:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23069 for ; Thu, 28 Apr 2005 04:26:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S8IWjn006070; Thu, 28 Apr 2005 01:18:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3S8IWt7006069; Thu, 28 Apr 2005 01:18:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S8IVhe006025 for ; Thu, 28 Apr 2005 01:18:31 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1059254wra for ; Thu, 28 Apr 2005 01:18:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Yksb/JdqNaDy4Hj9mYBJYy3XbCl6ehA+pXQl9d1mX9kYJ/W1NS7Ozu+yWgfBZOYTxYEOJhkUkJ7eEXYjzsHZT0kQ1TSoZbF/X4VCGUje/4jS+JX77JD1noOugEFWz8pf/Qh6aE39tpxXAkdCJQH3lanxNRP2Qggn+e2UXiL1V4s= Received: by 10.54.120.5 with SMTP id s5mr621851wrc; Thu, 28 Apr 2005 01:18:26 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 28 Apr 2005 01:18:26 -0700 (PDT) Message-ID: <68fba5c5050428011829c75f7f@mail.gmail.com> Date: Thu, 28 Apr 2005 04:18:26 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: PaceOptionalSummary Cc: atom-syntax In-Reply-To: <42709698.1080705@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> <426EF42C.5010505@intertwingly.net> <68fba5c505042619152ad7b5f6@mail.gmail.com> <426EFA35.8010103@intertwingly.net> <68fba5c505042707387c289d87@mail.gmail.com> <540e37320504272145dc0dd8c@mail.gmail.com> <68fba5c505042722395e8c66a@mail.gmail.com> <42709698.1080705@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3S8IWhe006061 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/28/05, Sam Ruby wrote: > Robert: why did you ask for an example? > To find out about any technical issues, not to hear Roger repeat himself. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 28 05:19:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26624 for ; Thu, 28 Apr 2005 05:19:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S9Bc8N026773; Thu, 28 Apr 2005 02:11:38 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3S9BcXU026771; Thu, 28 Apr 2005 02:11:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3S9BaHQ026714 for ; Thu, 28 Apr 2005 02:11:37 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 44040 messnum 6387907 invoked from network[83.70.217.193/unknown]); 28 Apr 2005 09:11:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail00.svc.cra.dublin.eircom.net (qp 44040) with SMTP; 28 Apr 2005 09:11:31 -0000 Message-ID: <4270A8BF.6040505@dehora.net> Date: Thu, 28 Apr 2005 10:11:27 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: atom-syntax Syntax , iesg@ietf.org Subject: Re: PaceOptionalSummary References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <426DFD9F.1080707@dehora.net> In-Reply-To: <426DFD9F.1080707@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > > Tim Bray wrote: > >> http://www.intertwingly.net/wiki/pie/PaceOptionalSummary > > > 0 I think I'm the only 0 in this. After watching the debate progress over the last few days, I'm altering my position to +1. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 28 05:20:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26658 for ; Thu, 28 Apr 2005 05:20:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S9ClHG027268; Thu, 28 Apr 2005 02:12:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3S9Cl8f027267; Thu, 28 Apr 2005 02:12:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3S9Cijs027200 for ; Thu, 28 Apr 2005 02:12:47 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 96297 messnum 5766325 invoked from network[83.70.217.193/unknown]); 28 Apr 2005 09:12:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail12.svc.cra.dublin.eircom.net (qp 96297) with SMTP; 28 Apr 2005 09:12:39 -0000 Message-ID: <4270A903.6070903@dehora.net> Date: Thu, 28 Apr 2005 10:12:35 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: On SHOULD, MUST, and semantics References: <426FC2A3.6000108@intertwingly.net> <68fba5c50504271003b63ab2d@mail.gmail.com> <426FF269.2030302@intertwingly.net> <68fba5c505042714312eeb0a58@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > On 27 Apr 2005, at 10:31 pm, Robert Sayre wrote: > >> My opinion is that ~10 WG members are currently clearly stating their >> belief that summary/content are optional. > > > You should make clear that most of those people supported a misleading > Pace that didn't clearly state its side-effects beyond making > feeds-where-no-title-is-available legal. Whether or not they support the > general position that "summary/content are optional" is not for you to > make. But yet you can make the judgement that people supported a misleading pace. This does not seem to be a reasonable or useful argument to make. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 28 05:56:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28757 for ; Thu, 28 Apr 2005 05:56:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3S9mCbt041590; Thu, 28 Apr 2005 02:48:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3S9mCAO041589; Thu, 28 Apr 2005 02:48:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3S9mBUS041542 for ; Thu, 28 Apr 2005 02:48:12 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 57626 messnum 2878128 invoked from network[83.70.217.193/unknown]); 28 Apr 2005 09:48:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail09.svc.cra.dublin.eircom.net (qp 57626) with SMTP; 28 Apr 2005 09:48:06 -0000 Message-ID: <4270B152.5010403@dehora.net> Date: Thu, 28 Apr 2005 10:48:02 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'atom-syntax Syntax''" Subject: Re: Cleanup phase References: <200504271548.DAO13916@ms8.netsolmail.com> <426FB837.8050905@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > And of course we're going to have to fish some sort of > consensus out of this horrid summary-required mess. -Tim I can't agree with that observation. Although there are a few strenuous objections against title only feeds, on the balance consensus is for them. Is there something you're seeing that should make us think the current consensus level is inadequate? cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 28 06:26:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00115 for ; Thu, 28 Apr 2005 06:26:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SAH9cG053184; Thu, 28 Apr 2005 03:17:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SAH9D9053183; Thu, 28 Apr 2005 03:17:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SAH88T053154 for ; Thu, 28 Apr 2005 03:17:08 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3SAEQ9D003080; Thu, 28 Apr 2005 11:14:37 +0100 (BST) In-Reply-To: <4270B152.5010403@dehora.net> References: <200504271548.DAO13916@ms8.netsolmail.com> <426FB837.8050905@intertwingly.net> <4270B152.5010403@dehora.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <41abda5c2d27e46fcb07f2a146431092@mac.com> Cc: atom-syntax From: Graham Subject: Re: Cleanup phase Date: Thu, 28 Apr 2005 11:14:21 +0100 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3SAH98T053177 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 28 Apr 2005, at 10:48 am, Bill de hÓra wrote: > > Tim Bray wrote: >> And of course we're going to have to fish some sort of consensus out >> of this horrid summary-required mess. -Tim > > I can't agree with that observation. Although there are a few > strenuous objections against title only feeds, on the balance > consensus is for them. Is there something you're seeing that should > make us think the current consensus level is inadequate? Exactly because the two sides don't understand each other. I haven't seen any objections to "title only feeds" which you state is my and Sam's and other's position (we object to feeds that could have a summary included but don't). Similarly, it's not clear whether people on your side would equally support an alternate proposal to the current Pace. Graham From owner-atom-syntax@mail.imc.org Thu Apr 28 06:42:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01464 for ; Thu, 28 Apr 2005 06:42:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SAYJbP060202; Thu, 28 Apr 2005 03:34:19 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SAYJLm060201; Thu, 28 Apr 2005 03:34:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3SAYIYB060151 for ; Thu, 28 Apr 2005 03:34:18 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 75465 messnum 3318699 invoked from network[83.70.217.193/unknown]); 28 Apr 2005 10:34:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail05.svc.cra.dublin.eircom.net (qp 75465) with SMTP; 28 Apr 2005 10:34:12 -0000 Message-ID: <4270BC20.2000302@dehora.net> Date: Thu, 28 Apr 2005 11:34:08 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: Cleanup phase References: <200504271548.DAO13916@ms8.netsolmail.com> <426FB837.8050905@intertwingly.net> <4270B152.5010403@dehora.net> <41abda5c2d27e46fcb07f2a146431092@mac.com> In-Reply-To: <41abda5c2d27e46fcb07f2a146431092@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Graham wrote: > On 28 Apr 2005, at 10:48 am, Bill de hÓra wrote: > >> >> Tim Bray wrote: >> >>> And of course we're going to have to fish some sort of consensus out >>> of this horrid summary-required mess. -Tim >> >> >> I can't agree with that observation. Although there are a few >> strenuous objections against title only feeds, on the balance >> consensus is for them. Is there something you're seeing that should >> make us think the current consensus level is inadequate? > > > Exactly because the two sides don't understand each other. I believe I understand the positions quite well. But maybe you can convince me otherwise. > I haven't > seen any objections to "title only feeds" which you state is my and > Sam's and other's position (we object to feeds that could have a summary > included but don't). That last objection in parens sounds like some of the positions held around dates - that providers ought to do the right thing for some definition of the right thing. Given that legacy, I'll claim it's clear we're not here to police what people ought do with feeds that could have a summary. The single argument along those lines that was sensible was to accessibility, which was eventually dispensed with. And if Robert's assertion elsewhere ("Every bit of syndication code written since my.netscape.com in 1999 can deal with title-only feed") is remotely true , ie there's not large number of codebases that will break, then you can add innovation through standards to my list of objections to any position that makes summaries non-optional. > Similarly, it's not clear whether people on your > side would equally support an alternate proposal to the current Pace. Any number of such counter-factual arguments can be made (after all that's largely the point of introducing them). They won't convince me, nor are they a basis for getting our work done. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 28 07:16:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04414 for ; Thu, 28 Apr 2005 07:16:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SB5F3Z073008; Thu, 28 Apr 2005 04:05:15 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SB5Fxe073006; Thu, 28 Apr 2005 04:05:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SB5Dc4072905 for ; Thu, 28 Apr 2005 04:05:14 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3SB4aq9003971; Thu, 28 Apr 2005 12:04:36 +0100 (BST) In-Reply-To: <4270BC20.2000302@dehora.net> References: <200504271548.DAO13916@ms8.netsolmail.com> <426FB837.8050905@intertwingly.net> <4270B152.5010403@dehora.net> <41abda5c2d27e46fcb07f2a146431092@mac.com> <4270BC20.2000302@dehora.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5c982c9c3a0cd27d411ef4b288e6833b@mac.com> Cc: atom-syntax From: Graham Subject: Re: Cleanup phase Date: Thu, 28 Apr 2005 12:04:30 +0100 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3SB5Fc4072994 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 28 Apr 2005, at 11:34 am, Bill de hÓra wrote: >> I haven't seen any objections to "title only feeds" which you state >> is my and Sam's and other's position (we object to feeds that could >> have a summary included but don't). > > That last objection in parens sounds like some of the positions held > around dates - that providers ought to do the right thing for some > definition of the right thing. Given that legacy, I'll claim it's > clear we're not here to police what people ought do with feeds that > could have a summary. Then what are we here to do? Would you support removing all of the other requirements from the spec? > And if Robert's assertion elsewhere ("Every bit of syndication code > written since my.netscape.com in 1999 can deal with title-only feed") > is remotely true , ie there's not large number of codebases that will > break, then you can add innovation through standards to my list of > objections to any position that makes summaries non-optional. Every code base can also cope without dates or ids. We still require them. Graham Parks From owner-atom-syntax@mail.imc.org Thu Apr 28 07:23:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04842 for ; Thu, 28 Apr 2005 07:23:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SBGsnK077719; Thu, 28 Apr 2005 04:16:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SBGrkk077713; Thu, 28 Apr 2005 04:16:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SBGonT077676 for ; Thu, 28 Apr 2005 04:16:51 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1222299wri for ; Thu, 28 Apr 2005 04:16:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nBYxWnGm2AtSK1kkPfqQb/L52cjnkJR4Tb6QPqMMVWRH3nMt1a2AkBZYIAfrpiRaVEKAdbD/WpDPQFfO/ehl/XMy4GCb22gBHcIvWbvSq4I3q9ds5hgdLFOkCTGTURetcvfQMrtWcR5+NgYCqKoGhiaFsPGO16g3d8wFoF0nFxU= Received: by 10.54.21.23 with SMTP id 23mr685405wru; Thu, 28 Apr 2005 04:16:45 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Thu, 28 Apr 2005 04:16:45 -0700 (PDT) Message-ID: <540e373205042804167e0b6fa9@mail.gmail.com> Date: Thu, 28 Apr 2005 06:16:45 -0500 From: "Roger B." Reply-To: "Roger B." To: Eric Scheid Subject: Re: PaceOptionalSummary Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <540e37320504272145dc0dd8c@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3SBGpnT077699 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Sorry, what was your point again? Eric: The point was that the *application* drops title- or content-free entries. It never inserts them into the database. They go poof. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Thu Apr 28 07:38:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06422 for ; Thu, 28 Apr 2005 07:38:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SBUdrq083375; Thu, 28 Apr 2005 04:30:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SBUdto083374; Thu, 28 Apr 2005 04:30:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SBUcxP083357 for ; Thu, 28 Apr 2005 04:30:38 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.103] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3S9YhEF031103; Thu, 28 Apr 2005 05:34:43 -0400 Message-ID: <4270C956.1060308@intertwingly.net> Date: Thu, 28 Apr 2005 07:30:30 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: atom-syntax , Graham Subject: Re: Cleanup phase References: <200504271548.DAO13916@ms8.netsolmail.com> <426FB837.8050905@intertwingly.net> <4270B152.5010403@dehora.net> <41abda5c2d27e46fcb07f2a146431092@mac.com> <4270BC20.2000302@dehora.net> <5c982c9c3a0cd27d411ef4b288e6833b@mac.com> In-Reply-To: <5c982c9c3a0cd27d411ef4b288e6833b@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Graham wrote: > > On 28 Apr 2005, at 11:34 am, Bill de hÓra wrote: > >>> I haven't seen any objections to "title only feeds" which you state >>> is my and Sam's and other's position (we object to feeds that could >>> have a summary included but don't). >> >> That last objection in parens sounds like some of the positions held >> around dates - that providers ought to do the right thing for some >> definition of the right thing. Given that legacy, I'll claim it's >> clear we're not here to police what people ought do with feeds that >> could have a summary. > > Then what are we here to do? Would you support removing all of the other > requirements from the spec? > >> And if Robert's assertion elsewhere ("Every bit of syndication code >> written since my.netscape.com in 1999 can deal with title-only feed") >> is remotely true , ie there's not large number of codebases that will >> break, then you can add innovation through standards to my list of >> objections to any position that makes summaries non-optional. First, note that this is mistating Graham's position. He is not arguing that summaries be made non-optional. > Every code base can also cope without dates or ids. We still require them. This is not a theoretical discussion. Quoting from RSS 0.92[1]: * All sub-elements of are optional * any 0.92 source is also a valid 2.0 source Is this really where we want to go? - Sam Ruby [1] http://backend.userland.com/rss092 From owner-atom-syntax@mail.imc.org Thu Apr 28 07:53:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07146 for ; Thu, 28 Apr 2005 07:53:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SBkn56090290; Thu, 28 Apr 2005 04:46:49 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SBknZ2090289; Thu, 28 Apr 2005 04:46:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SBkmEU090239 for ; Thu, 28 Apr 2005 04:46:48 -0700 (PDT) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1234642wri for ; Thu, 28 Apr 2005 04:46:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cy1oV+ITCKJaMggc8vkVzJZWwxuqQhjWi8dPcGzxEB8aQYILyCZiJl7u+7PPuh48+ECIA74a3hgjJgOnxSfKa6NLq8hi7ns9iz2KX0XfWc5whmiLx2XP6JEpvQcO9/cOwLyWwPBc6s/seN5glvXcn3zJzoLdpuEdE51XL/aLPQc= Received: by 10.54.27.16 with SMTP id a16mr1052641wra; Thu, 28 Apr 2005 04:46:42 -0700 (PDT) Received: by 10.54.95.11 with HTTP; Thu, 28 Apr 2005 04:46:42 -0700 (PDT) Message-ID: <540e3732050428044672abdc25@mail.gmail.com> Date: Thu, 28 Apr 2005 06:46:42 -0500 From: "Roger B." Reply-To: "Roger B." To: atom-syntax Subject: Re: PaceOptionalSummary In-Reply-To: <68fba5c505042722395e8c66a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> <426EF42C.5010505@intertwingly.net> <68fba5c505042619152ad7b5f6@mail.gmail.com> <426EFA35.8010103@intertwingly.net> <68fba5c505042707387c289d87@mail.gmail.com> <540e37320504272145dc0dd8c@mail.gmail.com> <68fba5c505042722395e8c66a@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3SBkmEU090283 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > That's fine, but we're not here to tailor the format to your app. Robert: Seriously, dude. C'mon. I don't care what little slap-fight you want to have with Sam, or Graham, or whoever else you figure is wronging the sublime rightness of your position. That's your thing, and welcome to it. You're not the first one to feel like "consensus" led Atom somewhere it had no business going. If you want to sit around and bitch about it, I'll might even join in. I was most unhappy with how things went in the XML-RPC vs. REST debate, for example. I've moved on, but I can at least sympathize. But you asked a question, and I answered it. Honestly, straightforwardly, and without an weasel-words. I did not ask anyone to tailor anything to anything. Try that silly crap with others if you must, but spare me. > I've > gotten feedback from embedded device developers complaining that XHTML > requires them to do more parsing than their app can handle, for little > practical benefit (for them). Note that we're also giving them the > short end of the stick with this requirement. If their embedded devices can't easily produce XHTML, then they don't have to do so. If their devices can't easily consume XHTML, they can either strip it or drop it. Again, the one thing Atom actually brings to the table over RSS is that content is clearly flagged. So where's the problem? (Or did someone slip something into 08 that says summaries must be XHTML?) > This is the assertion I have a problem with, and the opinions > expressed by others echo my gripe. Which part is the assertion that's causing you trouble? 'Cause half is in the charter, and the other half is one of those obvious things that Paul referenced. > Well, now we're just back to the sorts of feeds that are supposedly > perfectly ok on the condition that they contain an empty summary > element. Again, I support a SHOULD on summary. Not just adding an empty element... allowing publishers to drop it entirely, as long as they're aware they're doing something that will have an impact on the primary functionality of feed-consuming applications. Not that I think SHOULD is a good idea in this case. I just don't see the point in arguing about it incessantly, and SHOULD covers most of the bases. -- Roger Benningfield From owner-atom-syntax@mail.imc.org Thu Apr 28 08:09:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08572 for ; Thu, 28 Apr 2005 08:09:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SC0oxo095695; Thu, 28 Apr 2005 05:00:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SC0or9095694; Thu, 28 Apr 2005 05:00:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail10.svc.cra.dublin.eircom.net (mail10.svc.cra.dublin.eircom.net [159.134.118.26]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3SC0mNo095656 for ; Thu, 28 Apr 2005 05:00:49 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 29908 messnum 6684630 invoked from network[83.70.217.193/unknown]); 28 Apr 2005 12:00:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail10.svc.cra.dublin.eircom.net (qp 29908) with SMTP; 28 Apr 2005 12:00:43 -0000 Message-ID: <4270D067.5090000@dehora.net> Date: Thu, 28 Apr 2005 13:00:39 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax Subject: Re: Cleanup phase References: <200504271548.DAO13916@ms8.netsolmail.com> <426FB837.8050905@intertwingly.net> <4270B152.5010403@dehora.net> <41abda5c2d27e46fcb07f2a146431092@mac.com> <4270BC20.2000302@dehora.net> <5c982c9c3a0cd27d411ef4b288e6833b@mac.com> <4270C956.1060308@intertwingly.net> In-Reply-To: <4270C956.1060308@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > This is not a theoretical discussion. Quoting from RSS 0.92[1]: > > * All sub-elements of are optional > * any 0.92 source is also a valid 2.0 source > > Is this really where we want to go? No, but please see my other mail replying to Graham on why I think PaceOptionalSummary does not go there. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 28 08:12:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08689 for ; Thu, 28 Apr 2005 08:12:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SC4sFn097449; Thu, 28 Apr 2005 05:04:54 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SC4ssj097448; Thu, 28 Apr 2005 05:04:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail10.svc.cra.dublin.eircom.net (mail10.svc.cra.dublin.eircom.net [159.134.118.26]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3SC4r2N097418 for ; Thu, 28 Apr 2005 05:04:53 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 42371 messnum 6685818 invoked from network[83.70.217.193/unknown]); 28 Apr 2005 12:04:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail10.svc.cra.dublin.eircom.net (qp 42371) with SMTP; 28 Apr 2005 12:04:47 -0000 Message-ID: <4270D15C.2010406@dehora.net> Date: Thu, 28 Apr 2005 13:04:44 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: atom-syntax Subject: Re: Cleanup phase References: <200504271548.DAO13916@ms8.netsolmail.com> <426FB837.8050905@intertwingly.net> <4270B152.5010403@dehora.net> <41abda5c2d27e46fcb07f2a146431092@mac.com> <4270BC20.2000302@dehora.net> <5c982c9c3a0cd27d411ef4b288e6833b@mac.com> In-Reply-To: <5c982c9c3a0cd27d411ef4b288e6833b@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> Bill: >> That last objection in parens sounds like some of the positions held >> around dates - that providers ought to do the right thing for some >> definition of the right thing. Given that legacy, I'll claim it's >> clear we're not here to police what people ought do with feeds that >> could have a summary. > > Graham: > Then what are we here to do? Would you support removing all of the other > requirements from the spec? > Sam: > First, note that this is misstating Graham's position. > He is not arguing that summaries be made non-optional. I support discussing requirements that can be framed operationally and which induce a benefit. This is why I keep coming back to title-only feeds rather than concerning myself with enforcing some sort of policy on what people think other people ought to do with summaries. Rationales along the lines of "we object to feeds that could have a summary included but don't", don't work for me, and I'll try to explain why here. I also (and this is possibly unfair to Graham) think that when counter-factual arguments are being presented against, then the argument against the pace are running out of steam. >> And if Robert's assertion elsewhere ("Every bit of syndication code >> written since my.netscape.com in 1999 can deal with title-only feed") >> is remotely true , ie there's not large number of codebases that will >> break, then you can add innovation through standards to my list of >> objections to any position that makes summaries non-optional. > > > Every code base can also cope without dates or ids. We still require them. Yes, and there we agreed not to require enforcing publishers to update on every change and have 3 date items to support that policy. Largely because it can't be enforced and downstream clients will end up baking bad assumptions into their tools. My point here is probably worth elaborating on. I feel the same way about the must-be including summaries because you should be including summaries position, as I did about the must be updating dates because you should be updating dates position, that they are usefully enforceable. I also feel the same way about insisting on empty summary elements if that is used to obtain a compromise. I'm well aware of SHOULDs and optionals causing interop issues, however this must have summary approach, like must update timestamps, is not the kind of constraint that induces useful behaviour. I've read and re-read the -1 positions to PaceOptionalSummary and I can neither see the harm in optional summaries nor the benefit in always having a summary. That is, operationally, I can't see what harm is caused by allowing title-only feeds or what the benefit of disallowing them is. But I can see the pointlessness, if not quite harm, of making people populate a field they either don't need or don't want to populate. I suspect that might induce junk data unneccesarily. I believe I understand the -1 position, but I just haven't be swayed by the arguments for it; that leaves me at +1. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 28 10:03:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17175 for ; Thu, 28 Apr 2005 10:03:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SDrK28033247; Thu, 28 Apr 2005 06:53:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SDrKKA033246; Thu, 28 Apr 2005 06:53:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SDrIfm033219 for ; Thu, 28 Apr 2005 06:53:19 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1188130wra for ; Thu, 28 Apr 2005 06:53:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dBrLFXEDKfIheN7CZpQ07enPG9AwksqLKiFiLK2+MZEBAdXUxJv+K0mLo3VcIosHfCmUrWodalUuisAl4NRDah4R3HTzkyOALNCwIXsTxfXYxrIgaNM5LSPZTYz2lKzalNLTzgmpK0IK1PoH1sApIAVJmtscsEveIpRf2+OfpL8= Received: by 10.54.121.18 with SMTP id t18mr251171wrc; Thu, 28 Apr 2005 06:53:12 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 28 Apr 2005 06:53:11 -0700 (PDT) Message-ID: <68fba5c505042806533cb12fa8@mail.gmail.com> Date: Thu, 28 Apr 2005 09:53:11 -0400 From: Robert Sayre Reply-To: Robert Sayre To: "Roger B." Subject: Re: PaceOptionalSummary Cc: atom-syntax In-Reply-To: <540e3732050428044672abdc25@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> <426EF42C.5010505@intertwingly.net> <68fba5c505042619152ad7b5f6@mail.gmail.com> <426EFA35.8010103@intertwingly.net> <68fba5c505042707387c289d87@mail.gmail.com> <540e37320504272145dc0dd8c@mail.gmail.com> <68fba5c505042722395e8c66a@mail.gmail.com> <540e3732050428044672abdc25@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3SDrJfm033237 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/28/05, Roger B. wrote: > > > That's fine, but we're not here to tailor the format to your app. > > Robert: Seriously, dude. C'mon. > You're right, that was too snippy. > But you asked a question, and I answered it. Honestly, > straightforwardly, and without an weasel-words. I did not ask anyone > to tailor anything to anything. Try that silly crap with others if you > must, but spare me. > Again, I support a SHOULD on summary. Not just adding an empty > element... allowing publishers to drop it entirely, as long as they're > aware they're doing something that will have an impact on the primary > functionality of feed-consuming applications. Your argument is mostly consistent. I'll try to explain why SHOULD will create problems that don't exist today. Let's take del.icio.us. Sometimes, their entries have descriptions. Sometimes, they don't. Your SHOULD allows competitors to turn off their feeds at any time, and point to the spec as justification. Even worse, it could be "oh, some of their entries are buggy, so we drop those." I doubt your intent is anything nearly that malicious, and you might be right that the feeds in question suck, but using a SHOULD to back up that action is exactly what we want to avoid. It might even be possible to write a naive parser that actually malfunctioned on such feeds. Basically, if what you say is true, we don't need to enforce a summary at all. It'll take care of itself, like email and even HTML eventually did (it's possible to create an entire page in Flash, but not particularly effective in the market). If these sorts of feeds are legitimate for a certain style of application, a SHOULD is bound to bring questions my way wondering "what does that SHOULD *really* mean?". If that were to happen, the only ethical thing to do would be to refer the question to Mark Nottingham. I've begun training an email filter to forward questions to him ;) That is not a problem worth creating in return for advocating the type of feed we think is cool right now. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 28 10:45:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22342 for ; Thu, 28 Apr 2005 10:45:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SEbLUu043008; Thu, 28 Apr 2005 07:37:21 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SEbLSV043007; Thu, 28 Apr 2005 07:37:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SEbKX1042880 for ; Thu, 28 Apr 2005 07:37:20 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc13) with SMTP id <2005042814363001500501c2e>; Thu, 28 Apr 2005 14:36:30 +0000 Date: Thu, 28 Apr 2005 08:36:28 -0600 Subject: Re: Cleanup phase - remaining Paces Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The following Paces have not had their fate officially decided: PaceOptionalSummary (+1) PaceXmlContentWrapper (+1 -- there was plenty of opposition during the discussion of this one, but it seemed to be directed at both the current spec and the Pace, so I don't think it's clear whether people prefer the current spec or the Pace) PaceCoConstraintsAreBad (written to draft 07 but I don't think the section to be changed changed since then) PaceFeedIdOrAlternate (withdrawn by the author, so perhaps it shouldn't be listed here--written to draft 07 but the line in question hasn't changed since at least 06) PaceFeedIdOrSelf (+1 -- just updated to draft 08 by changing a "6" to an "8") Would a Pace be required to change the name of atom:image to atom:logo or could that be considered editorial? "Logo" is much more descriptive of what it's for, and would reduce confusion if somebody creates an extension for non-logo images. I assume a Pace is coming for atom:id being repeatable within a document as long as the entries in question have different source feeds? (I'd give it a +1) From owner-atom-syntax@mail.imc.org Thu Apr 28 11:19:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25791 for ; Thu, 28 Apr 2005 11:19:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SF5f14047427; Thu, 28 Apr 2005 08:05:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SF5fhK047426; Thu, 28 Apr 2005 08:05:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SF5ec1047407 for ; Thu, 28 Apr 2005 08:05:40 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so1232732wra for ; Thu, 28 Apr 2005 08:05:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=G1EN3yLR+dpfoDRZCV9L5Lreqy779eMx+k/XIrkuaWo8IiXy3GsTbMWCind5IdTe/3TXo+4TDRPZ/s39BwdtjaaVLv/fdPl7pHUPoxj07sFxZ4FQNwCyLeD1UF0LMxHLHchseURetBUTP0vTOC/Q9R73DFkecl8o5yaTOKbOeZU= Received: by 10.54.121.5 with SMTP id t5mr503340wrc; Thu, 28 Apr 2005 08:05:31 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Thu, 28 Apr 2005 08:05:31 -0700 (PDT) Message-ID: <68fba5c5050428080545ffc1eb@mail.gmail.com> Date: Thu, 28 Apr 2005 11:05:31 -0400 From: Robert Sayre Reply-To: Robert Sayre To: atom-syntax@imc.org Subject: PaceBriefExample posted Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3SF5ec1047420 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit I'm obviously very down on normative language requiring a summary. I am open to non-normative language explaining the syndication medium as we see it today. I acknowledge that people who don't know what they're doing sometimes create unhappy users by providing title-only feeds. The examples, especially the ones at the top, should cater to people who don't know what they're doing. Please do not take this opportunity argue about PaceOptionalSummary. Feel free to use it as ammunition in one of the other threads, if you must. Abstract ---------------------------- Change the description of the first example, if PaceOptionalSummary is accepted. Status ---------------------------- Open Rationale ---------------------------- Most readers glance at examples, but don't read the rest of the spec. They should be steered towards the set of elements they probably want to be using. Proposal ---------------------------- Change the first line of section 1.2 from {{{ A minimal, single-entry Atom Feed Document: }}} to {{{ A brief, single-entry Atom Feed Document: }}} and keep the example as it is in format-08. From owner-atom-syntax@mail.imc.org Thu Apr 28 14:43:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12146 for ; Thu, 28 Apr 2005 14:43:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SIYOcO080290; Thu, 28 Apr 2005 11:34:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SIYOVV080289; Thu, 28 Apr 2005 11:34:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SIYJS8080271 for ; Thu, 28 Apr 2005 11:34:23 -0700 (PDT) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.2.153] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 28 Apr 2005 19:33:17 +0100 Message-ID: <42712C6D.4030905@isode.com> Date: Thu, 28 Apr 2005 19:33:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Mark Nottingham , Robert Sayre CC: iesg@ietf.org, atom-syntax@imc.org Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="KOI8-R"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The IESG wrote: >The IESG has received a request from the Atom Publishing Format and Protocol >WG to consider the following document: > >- 'The Atom Syndication Format ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2005-05-04. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt > > In general the document looks good to me. Some minor comments (and few questions), mostly nitpicking below: >3.1.1.1 Text > > Example atom:title with text content: > > ... > > Less: < > > ... > > If the value is "text", the content of the Text construct MUST NOT > contain child elements. Such text is intended to be presented to > humans in a readable fashion. Thus, Atom Processors MAY collapse > white-space (including line-breaks), Ok, maybe it is just me, but what does it mean to "collapse white-space"? Does this mean to replace FWS (in RFC 2822 sense) with a single space? > and display the text using > typographic techniques such as justification and proportional fonts. >4.1.3.3 Processing Model ... > 2. If the value of "type" is "html", the content of atom:content > MUST NOT contain child elements, and SHOULD be suitable for > handling as HTML [HTML]. The HTML markup must be escaped; for Should the "must" be changed to MUST here? > example, "
" as "<br>". The HTML markup SHOULD be such > that it could validly appear directly within an HTML
> element. Atom Processors that display the content MAY use the > markup to aid in displaying it. ... > 6. For all other values of "type", the content of atom:content MUST > be a valid Base64 encoding [RFC3548], which when decoded SHOULD I have to note that the RFC 3548 has 2 base64 alphabets: in section 3 and in section 4. You probably want the more common one in section 3, but this has to be stated explicitly. >6.3 Software Processing of Foreign Markup > ... > When unknown foreign markup is encountered in a Text Contruct or > atom:content element, software SHOULD ignore the markup and process > any text content of foreign elements as though the surrounding markup > were not present. I reread this paragraph few times and I am still not quite sure what the paragraph is trying to say. Is it trying to say "if the content of a foreign element looks like XML with unrecognized schema - just strip the markup and process the text"? Regards, Alexey From owner-atom-syntax@mail.imc.org Thu Apr 28 14:44:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12223 for ; Thu, 28 Apr 2005 14:44:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SIc895080820; Thu, 28 Apr 2005 11:38:08 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SIc8B3080819; Thu, 28 Apr 2005 11:38:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SIc7N5080812 for ; Thu, 28 Apr 2005 11:38:07 -0700 (PDT) (envelope-from verify@GoodbyeSpam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SIc7Cv005347; Thu, 28 Apr 2005 11:38:07 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SIc3Lw005327; Thu, 28 Apr 2005 11:38:03 -0700 To: ramin@wizen.com Subject: Re: PaceOptionalSummary Received: (qmail 30130 invoked by uid 89); 26 Apr 2005 22:00:57 -0000 Received: from mx1.hrnoc.net (216.120.232.254) by mailbox2.hrnoc.net with QMTP; 26 Apr 2005 22:00:57 -0000 Received: (qmail 19258 invoked by uid 513); 26 Apr 2005 22:00:50 -0000 Received: from owner-atom-syntax@mail.imc.org by mx1.hrnoc.net by uid 503 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.141121 secs); 26 Apr 2005 22:00:50 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx1.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.141121 secs) Received: from above.proper.com (208.184.76.39) by mx1.hrnoc.net with AES256-SHA encrypted SMTP; 26 Apr 2005 22:00:49 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLfa7o062245; Tue, 26 Apr 2005 14:41:36 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QLfaiq062244; Tue, 26 Apr 2005 14:41:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLfZri062223 for ; Tue, 26 Apr 2005 14:41:35 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so167953wra for ; Tue, 26 Apr 2005 14:41:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CxnPeGOBoQsMVE1ZdqngI0aQH7XcgKaYudnnZDPO4nXjE968Prk0aZD2cdKRhPozLriixn0+8/otUWPTSLlYmHicjMd9W/tCB5HIthtNfzDNBjNp11QpRFWZ+K48Pr16z7nLIlOLi7v/QcqdyeMoWCp6Btaj8ogD9rJep0+D3nA= Received: by 10.54.78.16 with SMTP id a16mr138515wrb; Tue, 26 Apr 2005 14:41:26 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 26 Apr 2005 14:41:26 -0700 (PDT) Message-ID: <68fba5c505042614414d34d4d3@mail.gmail.com> Date: Tue, 26 Apr 2005 17:41:26 -0400 From: Robert Sayre Reply-To: Robert Sayre Cc: atom-syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <68fba5c505042613534b9e1ade@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3QLfZri062239 List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [f1ee6a484a139d807637926c1a5aa0b2] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/26/05, Graham wrote: > If I write an app that needs to know whether an entry had a body that > was removed or is a title-only feed, uh, what's the difference. > it cannot interoperate with Atom > feeds under Tim's proposal because there is no difference between them. > This is totally an interoperability issue. Nonsense. None of Atom's elements communicate that information, and there is no requirement to do so. Next. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 28 17:44:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27565 for ; Thu, 28 Apr 2005 17:44:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbXqd013501; Thu, 28 Apr 2005 14:37:33 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SLbX87013500; Thu, 28 Apr 2005 14:37:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbXo4013493 for ; Thu, 28 Apr 2005 14:37:33 -0700 (PDT) (envelope-from verify@GoodbyeSpam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SLb2dQ003402; Thu, 28 Apr 2005 14:37:02 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLb2dH003400; Thu, 28 Apr 2005 14:37:02 -0700 To: ramin@wizen.com Subject: Re: PaceOptionalSummary Received: (qmail 89092 invoked by uid 89); 26 Apr 2005 23:09:06 -0000 Received: from mx1.hrnoc.net (216.120.232.254) by mailbox2.hrnoc.net with QMTP; 26 Apr 2005 23:09:06 -0000 Received: (qmail 31410 invoked by uid 513); 26 Apr 2005 23:08:58 -0000 Received: from owner-atom-syntax@mail.imc.org by mx1.hrnoc.net by uid 503 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.145519 secs); 26 Apr 2005 23:08:58 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx1.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.145519 secs) Received: from above.proper.com (208.184.76.39) by mx1.hrnoc.net with AES256-SHA encrypted SMTP; 26 Apr 2005 23:08:57 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QMqBRf074467; Tue, 26 Apr 2005 15:52:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QMqBUv074466; Tue, 26 Apr 2005 15:52:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3QMqAJY074444 for ; Tue, 26 Apr 2005 15:52:10 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 27371 messnum 5763667 invoked from network[83.70.217.193/unknown]); 26 Apr 2005 22:52:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail12.svc.cra.dublin.eircom.net (qp 27371) with SMTP; 26 Apr 2005 22:52:04 -0000 Message-ID: <426EC60F.10406@dehora.net> Date: Tue, 26 Apr 2005 23:51:59 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Robert Sayre , atom-syntax References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <68fba5c505042613534b9e1ade@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [a200bbb45a3488c0051ae2d5f31d17e8] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote: > >> On 4/26/05, Graham wrote: >> >>> Without knowing this (which it wouldn't under Tim's proposal), my app >>> can't reliably interoperate with yours. >> >> >> I have no idea what you're talking about. Do the feeds on >> craigslist.org interoperate? Yes or No? > > > Interoperate with what? > > If I write an app that needs to know whether an entry had a body that > was removed or is a title-only feed, it cannot interoperate with Atom > feeds under Tim's proposal because there is no difference between them. > This is totally an interoperability issue. I'm not sure what you're saying is sensible. If you wrote that app, you've gone beyond anything Atom format mandates. Getting on board with your app would induce bug compatability, not interop. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 28 17:45:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27611 for ; Thu, 28 Apr 2005 17:45:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbAxu013432; Thu, 28 Apr 2005 14:37:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SLbArJ013431; Thu, 28 Apr 2005 14:37:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLb93J013425 for ; Thu, 28 Apr 2005 14:37:09 -0700 (PDT) (envelope-from verify@GoodbyeSpam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SLb1dQ003395; Thu, 28 Apr 2005 14:37:01 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLb11m003386; Thu, 28 Apr 2005 14:37:01 -0700 To: ramin@wizen.com Subject: Re: PaceOptionalSummary Received: (qmail 89092 invoked by uid 89); 26 Apr 2005 23:09:06 -0000 Received: from mx1.hrnoc.net (216.120.232.254) by mailbox2.hrnoc.net with QMTP; 26 Apr 2005 23:09:06 -0000 Received: (qmail 31410 invoked by uid 513); 26 Apr 2005 23:08:58 -0000 Received: from owner-atom-syntax@mail.imc.org by mx1.hrnoc.net by uid 503 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.145519 secs); 26 Apr 2005 23:08:58 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx1.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.145519 secs) Received: from above.proper.com (208.184.76.39) by mx1.hrnoc.net with AES256-SHA encrypted SMTP; 26 Apr 2005 23:08:57 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QMqBRf074467; Tue, 26 Apr 2005 15:52:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QMqBUv074466; Tue, 26 Apr 2005 15:52:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3QMqAJY074444 for ; Tue, 26 Apr 2005 15:52:10 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 27371 messnum 5763667 invoked from network[83.70.217.193/unknown]); 26 Apr 2005 22:52:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail12.svc.cra.dublin.eircom.net (qp 27371) with SMTP; 26 Apr 2005 22:52:04 -0000 Message-ID: <426EC60F.10406@dehora.net> Date: Tue, 26 Apr 2005 23:51:59 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Robert Sayre , atom-syntax References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <68fba5c505042613534b9e1ade@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [1e6164e517606e932d6d98225d82c48a] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote: > >> On 4/26/05, Graham wrote: >> >>> Without knowing this (which it wouldn't under Tim's proposal), my app >>> can't reliably interoperate with yours. >> >> >> I have no idea what you're talking about. Do the feeds on >> craigslist.org interoperate? Yes or No? > > > Interoperate with what? > > If I write an app that needs to know whether an entry had a body that > was removed or is a title-only feed, it cannot interoperate with Atom > feeds under Tim's proposal because there is no difference between them. > This is totally an interoperability issue. I'm not sure what you're saying is sensible. If you wrote that app, you've gone beyond anything Atom format mandates. Getting on board with your app would induce bug compatability, not interop. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 28 17:46:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27742 for ; Thu, 28 Apr 2005 17:46:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbbL3013543; Thu, 28 Apr 2005 14:37:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SLbbqU013540; Thu, 28 Apr 2005 14:37:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbYw4013503 for ; Thu, 28 Apr 2005 14:37:34 -0700 (PDT) (envelope-from verify@GoodbyeSpam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SLbYdQ003890; Thu, 28 Apr 2005 14:37:34 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLbYA4003879; Thu, 28 Apr 2005 14:37:34 -0700 To: ramin@wizen.com Subject: Re: PaceOptionalSummary Received: (qmail 75094 invoked by uid 89); 27 Apr 2005 00:36:08 -0000 Received: from mx2.hrnoc.net (216.120.242.254) by mailbox2.hrnoc.net with QMTP; 27 Apr 2005 00:36:08 -0000 Received: (qmail 11833 invoked by uid 511); 27 Apr 2005 00:35:57 -0000 Received: from owner-atom-syntax@mail.imc.org by mx2.hrnoc.net by uid 502 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.110921 secs); 27 Apr 2005 00:35:57 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx2.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.110921 secs) Received: from above.proper.com (208.184.76.39) by mx2.hrnoc.net with AES256-SHA encrypted SMTP; 27 Apr 2005 00:35:57 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0RCTx089628; Tue, 26 Apr 2005 17:27:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R0RCTG089627; Tue, 26 Apr 2005 17:27:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0RBZq089613 for ; Tue, 26 Apr 2005 17:27:11 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so234882wra for ; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pUjpCLEfrGrdyD5CVqTQ5eT9pvp7fophehPIyD2vrjJx1sOgc2pn2t92/tWnh/3ysKZMkNH92L/gmTbbn1KM22xRlBiX3ybEHjOVvDjr4NauW1h7hLre67IOTrp5Ox2Fwyk5h9dnjR/gaKr82Gz8sS8mXs+SxP+5ciBKawQ5wjU= Received: by 10.54.120.13 with SMTP id s13mr193998wrc; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) Message-ID: <68fba5c50504261727634cbbb9@mail.gmail.com> Date: Tue, 26 Apr 2005 20:27:05 -0400 From: Robert Sayre Reply-To: Robert Sayre Cc: atom-syntax Syntax In-Reply-To: <540e373205042616487e57ecfc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <540e373205042616487e57ecfc@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3R0RBZq089622 List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [8e692c34d59f7892fdc3f86cb892ee0f] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/26/05, Roger B. wrote: > And so on... I honestly can't think of a single child of atom:entry > that is required for interop. Yeah, I agree. The WG does not, however. They do happen to agree with me on this issue. > No one needs Atom for producing a title-and-link feed. It's overkill, > and pointless. The juice in Atom is in the handling of content... > providing for explicit summaries, and clearly defined payload types. The juice in Atom has little to do with the syndication format. IDs and dates are big, though. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 28 17:47:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27793 for ; Thu, 28 Apr 2005 17:47:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLap6h013373; Thu, 28 Apr 2005 14:36:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SLap4C013372; Thu, 28 Apr 2005 14:36:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLaoq7013359 for ; Thu, 28 Apr 2005 14:36:50 -0700 (PDT) (envelope-from verify@GoodbyeSpam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SLaodQ003109; Thu, 28 Apr 2005 14:36:50 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLao99003098; Thu, 28 Apr 2005 14:36:50 -0700 To: ramin@wizen.com Subject: Re: PaceOptionalSummary Received: (qmail 16825 invoked by uid 89); 26 Apr 2005 21:57:52 -0000 Received: from mx2.hrnoc.net (216.120.242.254) by mailbox2.hrnoc.net with QMTP; 26 Apr 2005 21:57:52 -0000 Received: (qmail 9612 invoked by uid 511); 26 Apr 2005 21:57:42 -0000 Received: from owner-atom-syntax@mail.imc.org by mx2.hrnoc.net by uid 502 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.111959 secs); 26 Apr 2005 21:57:42 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx2.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.111959 secs) Received: from above.proper.com (208.184.76.39) by mx2.hrnoc.net with AES256-SHA encrypted SMTP; 26 Apr 2005 21:57:42 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLZoov061259; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QLZoMB061258; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLZnrx061235 for ; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3QLOfYZ016023; Tue, 26 Apr 2005 22:24:47 +0100 (BST) In-Reply-To: <68fba5c505042613534b9e1ade@mail.gmail.com> References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <68fba5c505042613534b9e1ade@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Date: Tue, 26 Apr 2005 22:24:38 +0100 X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [eff53af1cdd01d77b2822b43b63c6207] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote: > On 4/26/05, Graham wrote: >> Without knowing this (which it wouldn't under Tim's proposal), my app >> can't reliably interoperate with yours. > > I have no idea what you're talking about. Do the feeds on > craigslist.org interoperate? Yes or No? Interoperate with what? If I write an app that needs to know whether an entry had a body that was removed or is a title-only feed, it cannot interoperate with Atom feeds under Tim's proposal because there is no difference between them. This is totally an interoperability issue. Graham From owner-atom-syntax@mail.imc.org Thu Apr 28 17:47:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27819 for ; Thu, 28 Apr 2005 17:47:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbKuC013470; Thu, 28 Apr 2005 14:37:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SLbKRS013469; Thu, 28 Apr 2005 14:37:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbK1B013462 for ; Thu, 28 Apr 2005 14:37:20 -0700 (PDT) (envelope-from verify@GoodbyeSpam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SLb2dQ003397; Thu, 28 Apr 2005 14:37:02 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLb1UW003393; Thu, 28 Apr 2005 14:37:01 -0700 To: ramin@wizen.com Subject: Re: PaceOptionalSummary Received: (qmail 89092 invoked by uid 89); 26 Apr 2005 23:09:06 -0000 Received: from mx1.hrnoc.net (216.120.232.254) by mailbox2.hrnoc.net with QMTP; 26 Apr 2005 23:09:06 -0000 Received: (qmail 31410 invoked by uid 513); 26 Apr 2005 23:08:58 -0000 Received: from owner-atom-syntax@mail.imc.org by mx1.hrnoc.net by uid 503 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.145519 secs); 26 Apr 2005 23:08:58 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx1.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.145519 secs) Received: from above.proper.com (208.184.76.39) by mx1.hrnoc.net with AES256-SHA encrypted SMTP; 26 Apr 2005 23:08:57 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QMqBRf074467; Tue, 26 Apr 2005 15:52:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QMqBUv074466; Tue, 26 Apr 2005 15:52:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3QMqAJY074444 for ; Tue, 26 Apr 2005 15:52:10 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 27371 messnum 5763667 invoked from network[83.70.217.193/unknown]); 26 Apr 2005 22:52:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail12.svc.cra.dublin.eircom.net (qp 27371) with SMTP; 26 Apr 2005 22:52:04 -0000 Message-ID: <426EC60F.10406@dehora.net> Date: Tue, 26 Apr 2005 23:51:59 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Robert Sayre , atom-syntax References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <68fba5c505042613534b9e1ade@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [7885f4473c256ba8fcc83ab5d9755310] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote: > >> On 4/26/05, Graham wrote: >> >>> Without knowing this (which it wouldn't under Tim's proposal), my app >>> can't reliably interoperate with yours. >> >> >> I have no idea what you're talking about. Do the feeds on >> craigslist.org interoperate? Yes or No? > > > Interoperate with what? > > If I write an app that needs to know whether an entry had a body that > was removed or is a title-only feed, it cannot interoperate with Atom > feeds under Tim's proposal because there is no difference between them. > This is totally an interoperability issue. I'm not sure what you're saying is sensible. If you wrote that app, you've gone beyond anything Atom format mandates. Getting on board with your app would induce bug compatability, not interop. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 28 17:48:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27848 for ; Thu, 28 Apr 2005 17:48:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLauqH013408; Thu, 28 Apr 2005 14:36:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SLautM013407; Thu, 28 Apr 2005 14:36:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLatUm013396 for ; Thu, 28 Apr 2005 14:36:56 -0700 (PDT) (envelope-from verify@GoodbyeSpam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SLasdQ003229; Thu, 28 Apr 2005 14:36:54 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLasgS003226; Thu, 28 Apr 2005 14:36:54 -0700 To: ramin@wizen.com Subject: Re: PaceOptionalSummary Received: (qmail 16825 invoked by uid 89); 26 Apr 2005 21:57:52 -0000 Received: from mx2.hrnoc.net (216.120.242.254) by mailbox2.hrnoc.net with QMTP; 26 Apr 2005 21:57:52 -0000 Received: (qmail 9612 invoked by uid 511); 26 Apr 2005 21:57:42 -0000 Received: from owner-atom-syntax@mail.imc.org by mx2.hrnoc.net by uid 502 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.111959 secs); 26 Apr 2005 21:57:42 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx2.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.111959 secs) Received: from above.proper.com (208.184.76.39) by mx2.hrnoc.net with AES256-SHA encrypted SMTP; 26 Apr 2005 21:57:42 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLZoov061259; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QLZoMB061258; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLZnrx061235 for ; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3QLOfYZ016023; Tue, 26 Apr 2005 22:24:47 +0100 (BST) In-Reply-To: <68fba5c505042613534b9e1ade@mail.gmail.com> References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <68fba5c505042613534b9e1ade@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Date: Tue, 26 Apr 2005 22:24:38 +0100 X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [cc5105b38273017c6064d416ac0db10f] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote: > On 4/26/05, Graham wrote: >> Without knowing this (which it wouldn't under Tim's proposal), my app >> can't reliably interoperate with yours. > > I have no idea what you're talking about. Do the feeds on > craigslist.org interoperate? Yes or No? Interoperate with what? If I write an app that needs to know whether an entry had a body that was removed or is a title-only feed, it cannot interoperate with Atom feeds under Tim's proposal because there is no difference between them. This is totally an interoperability issue. Graham From owner-atom-syntax@mail.imc.org Thu Apr 28 17:48:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27875 for ; Thu, 28 Apr 2005 17:48:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbbfE013542; Thu, 28 Apr 2005 14:37:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SLbbC0013539; Thu, 28 Apr 2005 14:37:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbYQC013505 for ; Thu, 28 Apr 2005 14:37:34 -0700 (PDT) (envelope-from verify@GoodbyeSpam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SLbYdQ003893; Thu, 28 Apr 2005 14:37:34 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLbYHN003877; Thu, 28 Apr 2005 14:37:34 -0700 To: ramin@wizen.com Subject: Re: PaceOptionalSummary Received: (qmail 75094 invoked by uid 89); 27 Apr 2005 00:36:08 -0000 Received: from mx2.hrnoc.net (216.120.242.254) by mailbox2.hrnoc.net with QMTP; 27 Apr 2005 00:36:08 -0000 Received: (qmail 11833 invoked by uid 511); 27 Apr 2005 00:35:57 -0000 Received: from owner-atom-syntax@mail.imc.org by mx2.hrnoc.net by uid 502 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.110921 secs); 27 Apr 2005 00:35:57 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx2.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.110921 secs) Received: from above.proper.com (208.184.76.39) by mx2.hrnoc.net with AES256-SHA encrypted SMTP; 27 Apr 2005 00:35:57 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0RCTx089628; Tue, 26 Apr 2005 17:27:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R0RCTG089627; Tue, 26 Apr 2005 17:27:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0RBZq089613 for ; Tue, 26 Apr 2005 17:27:11 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so234882wra for ; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pUjpCLEfrGrdyD5CVqTQ5eT9pvp7fophehPIyD2vrjJx1sOgc2pn2t92/tWnh/3ysKZMkNH92L/gmTbbn1KM22xRlBiX3ybEHjOVvDjr4NauW1h7hLre67IOTrp5Ox2Fwyk5h9dnjR/gaKr82Gz8sS8mXs+SxP+5ciBKawQ5wjU= Received: by 10.54.120.13 with SMTP id s13mr193998wrc; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) Message-ID: <68fba5c50504261727634cbbb9@mail.gmail.com> Date: Tue, 26 Apr 2005 20:27:05 -0400 From: Robert Sayre Reply-To: Robert Sayre Cc: atom-syntax Syntax In-Reply-To: <540e373205042616487e57ecfc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <540e373205042616487e57ecfc@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3R0RBZq089622 List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [c26df8004c0a62693f579a3f1d09989e] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/26/05, Roger B. wrote: > And so on... I honestly can't think of a single child of atom:entry > that is required for interop. Yeah, I agree. The WG does not, however. They do happen to agree with me on this issue. > No one needs Atom for producing a title-and-link feed. It's overkill, > and pointless. The juice in Atom is in the handling of content... > providing for explicit summaries, and clearly defined payload types. The juice in Atom has little to do with the syndication format. IDs and dates are big, though. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 28 17:48:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27901 for ; Thu, 28 Apr 2005 17:48:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbK1s013478; Thu, 28 Apr 2005 14:37:20 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SLbKKo013477; Thu, 28 Apr 2005 14:37:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbK0X013467 for ; Thu, 28 Apr 2005 14:37:20 -0700 (PDT) (envelope-from verify@GoodbyeSpam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SLb1dQ003392; Thu, 28 Apr 2005 14:37:01 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLb0De003380; Thu, 28 Apr 2005 14:37:00 -0700 To: ramin@wizen.com Subject: Re: PaceOptionalSummary Received: (qmail 89092 invoked by uid 89); 26 Apr 2005 23:09:06 -0000 Received: from mx1.hrnoc.net (216.120.232.254) by mailbox2.hrnoc.net with QMTP; 26 Apr 2005 23:09:06 -0000 Received: (qmail 31410 invoked by uid 513); 26 Apr 2005 23:08:58 -0000 Received: from owner-atom-syntax@mail.imc.org by mx1.hrnoc.net by uid 503 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.145519 secs); 26 Apr 2005 23:08:58 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx1.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.145519 secs) Received: from above.proper.com (208.184.76.39) by mx1.hrnoc.net with AES256-SHA encrypted SMTP; 26 Apr 2005 23:08:57 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QMqBRf074467; Tue, 26 Apr 2005 15:52:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QMqBUv074466; Tue, 26 Apr 2005 15:52:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3QMqAJY074444 for ; Tue, 26 Apr 2005 15:52:10 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 27371 messnum 5763667 invoked from network[83.70.217.193/unknown]); 26 Apr 2005 22:52:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail12.svc.cra.dublin.eircom.net (qp 27371) with SMTP; 26 Apr 2005 22:52:04 -0000 Message-ID: <426EC60F.10406@dehora.net> Date: Tue, 26 Apr 2005 23:51:59 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Robert Sayre , atom-syntax References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <68fba5c505042613534b9e1ade@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [671fa05cfb817132c14f2de847dccbf1] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote: > >> On 4/26/05, Graham wrote: >> >>> Without knowing this (which it wouldn't under Tim's proposal), my app >>> can't reliably interoperate with yours. >> >> >> I have no idea what you're talking about. Do the feeds on >> craigslist.org interoperate? Yes or No? > > > Interoperate with what? > > If I write an app that needs to know whether an entry had a body that > was removed or is a title-only feed, it cannot interoperate with Atom > feeds under Tim's proposal because there is no difference between them. > This is totally an interoperability issue. I'm not sure what you're saying is sensible. If you wrote that app, you've gone beyond anything Atom format mandates. Getting on board with your app would induce bug compatability, not interop. cheers Bill From owner-atom-syntax@mail.imc.org Thu Apr 28 17:50:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27965 for ; Thu, 28 Apr 2005 17:50:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbbSk013538; Thu, 28 Apr 2005 14:37:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SLbbJT013536; Thu, 28 Apr 2005 14:37:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbYtw013509 for ; Thu, 28 Apr 2005 14:37:35 -0700 (PDT) (envelope-from verify@GoodbyeSpam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SLbYdQ003895; Thu, 28 Apr 2005 14:37:34 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLbYoY003881; Thu, 28 Apr 2005 14:37:34 -0700 To: ramin@wizen.com Subject: Re: PaceOptionalSummary Received: (qmail 75094 invoked by uid 89); 27 Apr 2005 00:36:08 -0000 Received: from mx2.hrnoc.net (216.120.242.254) by mailbox2.hrnoc.net with QMTP; 27 Apr 2005 00:36:08 -0000 Received: (qmail 11833 invoked by uid 511); 27 Apr 2005 00:35:57 -0000 Received: from owner-atom-syntax@mail.imc.org by mx2.hrnoc.net by uid 502 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.110921 secs); 27 Apr 2005 00:35:57 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx2.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.110921 secs) Received: from above.proper.com (208.184.76.39) by mx2.hrnoc.net with AES256-SHA encrypted SMTP; 27 Apr 2005 00:35:57 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0RCTx089628; Tue, 26 Apr 2005 17:27:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R0RCTG089627; Tue, 26 Apr 2005 17:27:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0RBZq089613 for ; Tue, 26 Apr 2005 17:27:11 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so234882wra for ; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pUjpCLEfrGrdyD5CVqTQ5eT9pvp7fophehPIyD2vrjJx1sOgc2pn2t92/tWnh/3ysKZMkNH92L/gmTbbn1KM22xRlBiX3ybEHjOVvDjr4NauW1h7hLre67IOTrp5Ox2Fwyk5h9dnjR/gaKr82Gz8sS8mXs+SxP+5ciBKawQ5wjU= Received: by 10.54.120.13 with SMTP id s13mr193998wrc; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) Message-ID: <68fba5c50504261727634cbbb9@mail.gmail.com> Date: Tue, 26 Apr 2005 20:27:05 -0400 From: Robert Sayre Reply-To: Robert Sayre Cc: atom-syntax Syntax In-Reply-To: <540e373205042616487e57ecfc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <540e373205042616487e57ecfc@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3R0RBZq089622 List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [04ddb27b959335ca24e2cfd5ca928c1d] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/26/05, Roger B. wrote: > And so on... I honestly can't think of a single child of atom:entry > that is required for interop. Yeah, I agree. The WG does not, however. They do happen to agree with me on this issue. > No one needs Atom for producing a title-and-link feed. It's overkill, > and pointless. The juice in Atom is in the handling of content... > providing for explicit summaries, and clearly defined payload types. The juice in Atom has little to do with the syndication format. IDs and dates are big, though. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 28 17:50:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28015 for ; Thu, 28 Apr 2005 17:50:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLatGf013394; Thu, 28 Apr 2005 14:36:55 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SLatWo013393; Thu, 28 Apr 2005 14:36:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLascV013385 for ; Thu, 28 Apr 2005 14:36:54 -0700 (PDT) (envelope-from verify@GoodbyeSpam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SLasdQ003228; Thu, 28 Apr 2005 14:36:54 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLas6X003221; Thu, 28 Apr 2005 14:36:54 -0700 To: ramin@wizen.com Subject: Re: PaceOptionalSummary Received: (qmail 16825 invoked by uid 89); 26 Apr 2005 21:57:52 -0000 Received: from mx2.hrnoc.net (216.120.242.254) by mailbox2.hrnoc.net with QMTP; 26 Apr 2005 21:57:52 -0000 Received: (qmail 9612 invoked by uid 511); 26 Apr 2005 21:57:42 -0000 Received: from owner-atom-syntax@mail.imc.org by mx2.hrnoc.net by uid 502 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.111959 secs); 26 Apr 2005 21:57:42 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx2.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.111959 secs) Received: from above.proper.com (208.184.76.39) by mx2.hrnoc.net with AES256-SHA encrypted SMTP; 26 Apr 2005 21:57:42 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLZoov061259; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QLZoMB061258; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLZnrx061235 for ; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3QLOfYZ016023; Tue, 26 Apr 2005 22:24:47 +0100 (BST) In-Reply-To: <68fba5c505042613534b9e1ade@mail.gmail.com> References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <68fba5c505042613534b9e1ade@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Date: Tue, 26 Apr 2005 22:24:38 +0100 X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [bc080e38f147c05185b7a633125a0e43] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote: > On 4/26/05, Graham wrote: >> Without knowing this (which it wouldn't under Tim's proposal), my app >> can't reliably interoperate with yours. > > I have no idea what you're talking about. Do the feeds on > craigslist.org interoperate? Yes or No? Interoperate with what? If I write an app that needs to know whether an entry had a body that was removed or is a title-only feed, it cannot interoperate with Atom feeds under Tim's proposal because there is no difference between them. This is totally an interoperability issue. Graham From owner-atom-syntax@mail.imc.org Thu Apr 28 17:51:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28113 for ; Thu, 28 Apr 2005 17:51:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbbCc013541; Thu, 28 Apr 2005 14:37:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SLbbRN013537; Thu, 28 Apr 2005 14:37:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLbYX7013504 for ; Thu, 28 Apr 2005 14:37:34 -0700 (PDT) (envelope-from verify@GoodbyeSpam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SLbYdQ003888; Thu, 28 Apr 2005 14:37:34 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLbYbH003883; Thu, 28 Apr 2005 14:37:34 -0700 To: ramin@wizen.com Subject: Re: PaceOptionalSummary Received: (qmail 75094 invoked by uid 89); 27 Apr 2005 00:36:08 -0000 Received: from mx2.hrnoc.net (216.120.242.254) by mailbox2.hrnoc.net with QMTP; 27 Apr 2005 00:36:08 -0000 Received: (qmail 11833 invoked by uid 511); 27 Apr 2005 00:35:57 -0000 Received: from owner-atom-syntax@mail.imc.org by mx2.hrnoc.net by uid 502 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.110921 secs); 27 Apr 2005 00:35:57 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx2.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.110921 secs) Received: from above.proper.com (208.184.76.39) by mx2.hrnoc.net with AES256-SHA encrypted SMTP; 27 Apr 2005 00:35:57 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0RCTx089628; Tue, 26 Apr 2005 17:27:12 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3R0RCTG089627; Tue, 26 Apr 2005 17:27:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3R0RBZq089613 for ; Tue, 26 Apr 2005 17:27:11 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so234882wra for ; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pUjpCLEfrGrdyD5CVqTQ5eT9pvp7fophehPIyD2vrjJx1sOgc2pn2t92/tWnh/3ysKZMkNH92L/gmTbbn1KM22xRlBiX3ybEHjOVvDjr4NauW1h7hLre67IOTrp5Ox2Fwyk5h9dnjR/gaKr82Gz8sS8mXs+SxP+5ciBKawQ5wjU= Received: by 10.54.120.13 with SMTP id s13mr193998wrc; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Tue, 26 Apr 2005 17:27:05 -0700 (PDT) Message-ID: <68fba5c50504261727634cbbb9@mail.gmail.com> Date: Tue, 26 Apr 2005 20:27:05 -0400 From: Robert Sayre Reply-To: Robert Sayre Cc: atom-syntax Syntax In-Reply-To: <540e373205042616487e57ecfc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <540e373205042616487e57ecfc@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3R0RBZq089622 List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [722d7ffbaa05503e06890fd4883dfa4f] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/26/05, Roger B. wrote: > And so on... I honestly can't think of a single child of atom:entry > that is required for interop. Yeah, I agree. The WG does not, however. They do happen to agree with me on this issue. > No one needs Atom for producing a title-and-link feed. It's overkill, > and pointless. The juice in Atom is in the handling of content... > providing for explicit summaries, and clearly defined payload types. The juice in Atom has little to do with the syndication format. IDs and dates are big, though. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Apr 28 17:53:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28428 for ; Thu, 28 Apr 2005 17:53:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLauhi013405; Thu, 28 Apr 2005 14:36:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SLauh6013401; Thu, 28 Apr 2005 14:36:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SLao80013360 for ; Thu, 28 Apr 2005 14:36:50 -0700 (PDT) (envelope-from verify@GoodbyeSpam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SLaodQ003108; Thu, 28 Apr 2005 14:36:50 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLaoUa003100; Thu, 28 Apr 2005 14:36:50 -0700 To: ramin@wizen.com Subject: Re: PaceOptionalSummary Received: (qmail 16825 invoked by uid 89); 26 Apr 2005 21:57:52 -0000 Received: from mx2.hrnoc.net (216.120.242.254) by mailbox2.hrnoc.net with QMTP; 26 Apr 2005 21:57:52 -0000 Received: (qmail 9612 invoked by uid 511); 26 Apr 2005 21:57:42 -0000 Received: from owner-atom-syntax@mail.imc.org by mx2.hrnoc.net by uid 502 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.111959 secs); 26 Apr 2005 21:57:42 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx2.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.111959 secs) Received: from above.proper.com (208.184.76.39) by mx2.hrnoc.net with AES256-SHA encrypted SMTP; 26 Apr 2005 21:57:42 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLZoov061259; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3QLZoMB061258; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3QLZnrx061235 for ; Tue, 26 Apr 2005 14:35:50 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3QLOfYZ016023; Tue, 26 Apr 2005 22:24:47 +0100 (BST) In-Reply-To: <68fba5c505042613534b9e1ade@mail.gmail.com> References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <540e3732050426123310883142@mail.gmail.com> <68fba5c505042612547933e9c5@mail.gmail.com> <68fba5c505042613534b9e1ade@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Date: Tue, 26 Apr 2005 22:24:38 +0100 X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [f37bc380879104456d132a27825fb391] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 26 Apr 2005, at 9:53 pm, Robert Sayre wrote: > On 4/26/05, Graham wrote: >> Without knowing this (which it wouldn't under Tim's proposal), my app >> can't reliably interoperate with yours. > > I have no idea what you're talking about. Do the feeds on > craigslist.org interoperate? Yes or No? Interoperate with what? If I write an app that needs to know whether an entry had a body that was removed or is a title-only feed, it cannot interoperate with Atom feeds under Tim's proposal because there is no difference between them. This is totally an interoperability issue. Graham From owner-atom-syntax@mail.imc.org Thu Apr 28 18:49:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04991 for ; Thu, 28 Apr 2005 18:49:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SMd9gl023536; Thu, 28 Apr 2005 15:39:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SMd9Q8023535; Thu, 28 Apr 2005 15:39:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SMd9BT023529 for ; Thu, 28 Apr 2005 15:39:09 -0700 (PDT) (envelope-from henry.story@bblfish.net) Received: (qmail 49927 invoked by uid 17064); 28 Apr 2005 22:39:06 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.143.116]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 28 Apr 2005 22:39:06 -0000 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <68fba5c50504261929339880ae@mail.gmail.com> References: <426D1F6E.60306@franklinmint.fm> <8023d024697429b8d95118f9d4a8a5c8@mac.com> <6d885e8145db474ec35d402a3b2d3b91@sun.com> <672bc8dc873220a2070555424e9f7e4d@sun.com> <68fba5c50504261929339880ae@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8974a06390f60ee00ddf68f50fc4a580@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceOptionalSummary Date: Fri, 29 Apr 2005 00:39:03 +0200 To: "'atom-syntax Syntax''" , Robert Sayre X-Mailer: Apple Mail (2.622) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'll +1 on MAY. On 27 Apr 2005, at 04:29, Robert Sayre wrote: > > On 4/26/05, Tim Bray wrote: > >> >> Paul & I are gonna watch a little more debate and then >> we'll call rough consensus one way or the other, at which point I at >> least will become crushingly rude to anyone who wants to invest more >> time in this. > > Yeah, so now Sam and Graham are off making up requirements to add to > the spec. This is over and its a waste of the WG's time. > > Let me summarize: > > MUST: Sam > SHOULD: Graham, Roger > Eh: Bill > MAY: Myself, James T, Antone, Eric, Julian, Martin, Aristotle > > Robert Sayre > From owner-atom-syntax@mail.imc.org Thu Apr 28 18:58:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05512 for ; Thu, 28 Apr 2005 18:58:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SMqqOn025582; Thu, 28 Apr 2005 15:52:52 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SMqqa7025581; Thu, 28 Apr 2005 15:52:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SMqo5H025575 for ; Thu, 28 Apr 2005 15:52:51 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 28 Apr 2005 15:52:49 -0700 To: Atom WG From: Paul Hoffman Subject: ADMINSTRIVIA: resent mail and loops Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There will probably be a couple of more re-sent messages before the current storm stops. I have nuked the user who seems to be behind a stupidly-written spam filter at fault. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Thu Apr 28 20:06:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10774 for ; Thu, 28 Apr 2005 20:06:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SNv4kF034084; Thu, 28 Apr 2005 16:57:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SNv4K8034081; Thu, 28 Apr 2005 16:57:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SNv32U034061 for ; Thu, 28 Apr 2005 16:57:03 -0700 (PDT) (envelope-from verify@goodbyespam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SNoPHg003518; Thu, 28 Apr 2005 16:57:03 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLSBMp029495; Thu, 28 Apr 2005 14:28:11 -0700 To: ramin@wizen.com Subject: Re: On SHOULD, MUST, and semantics Received: (qmail 86727 invoked by uid 89); 27 Apr 2005 23:29:17 -0000 Received: from mx1.hrnoc.net (216.120.232.254) by mailbox2.hrnoc.net with QMTP; 27 Apr 2005 23:29:17 -0000 Received: (qmail 13477 invoked by uid 513); 27 Apr 2005 23:29:07 -0000 Received: from owner-atom-syntax@mail.imc.org by mx1.hrnoc.net by uid 503 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.178867 secs); 27 Apr 2005 23:29:07 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx1.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.178867 secs) Received: from above.proper.com (208.184.76.39) by mx1.hrnoc.net with AES256-SHA encrypted SMTP; 27 Apr 2005 23:29:06 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RNCkT6001785; Wed, 27 Apr 2005 16:12:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RNCkPd001782; Wed, 27 Apr 2005 16:12:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RNChpd001774 for ; Wed, 27 Apr 2005 16:12:43 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3RNBfik015131; Thu, 28 Apr 2005 00:11:46 +0100 (BST) In-Reply-To: <68fba5c505042714312eeb0a58@mail.gmail.com> References: <426FC2A3.6000108@intertwingly.net> <68fba5c50504271003b63ab2d@mail.gmail.com> <426FF269.2030302@intertwingly.net> <68fba5c505042714312eeb0a58@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Date: Thu, 28 Apr 2005 00:11:39 +0100 X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [aceca7ff58bb15abd0ac1cbb44dc254c] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27 Apr 2005, at 10:31 pm, Robert Sayre wrote: > My opinion is that ~10 WG members are currently clearly stating their > belief that summary/content are optional. You should make clear that most of those people supported a misleading Pace that didn't clearly state its side-effects beyond making feeds-where-no-title-is-available legal. Whether or not they support the general position that "summary/content are optional" is not for you to make. Graham From owner-atom-syntax@mail.imc.org Thu Apr 28 20:06:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10802 for ; Thu, 28 Apr 2005 20:06:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SNv4Fk034082; Thu, 28 Apr 2005 16:57:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SNv4HM034079; Thu, 28 Apr 2005 16:57:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SNv38m034071 for ; Thu, 28 Apr 2005 16:57:03 -0700 (PDT) (envelope-from verify@goodbyespam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SNoPHk003518; Thu, 28 Apr 2005 16:57:03 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLSDUM029526; Thu, 28 Apr 2005 14:28:13 -0700 To: ramin@wizen.com Subject: Re: On SHOULD, MUST, and semantics Received: (qmail 86727 invoked by uid 89); 27 Apr 2005 23:29:17 -0000 Received: from mx1.hrnoc.net (216.120.232.254) by mailbox2.hrnoc.net with QMTP; 27 Apr 2005 23:29:17 -0000 Received: (qmail 13477 invoked by uid 513); 27 Apr 2005 23:29:07 -0000 Received: from owner-atom-syntax@mail.imc.org by mx1.hrnoc.net by uid 503 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.178867 secs); 27 Apr 2005 23:29:07 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx1.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.178867 secs) Received: from above.proper.com (208.184.76.39) by mx1.hrnoc.net with AES256-SHA encrypted SMTP; 27 Apr 2005 23:29:06 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RNCkT6001785; Wed, 27 Apr 2005 16:12:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RNCkPd001782; Wed, 27 Apr 2005 16:12:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RNChpd001774 for ; Wed, 27 Apr 2005 16:12:43 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3RNBfik015131; Thu, 28 Apr 2005 00:11:46 +0100 (BST) In-Reply-To: <68fba5c505042714312eeb0a58@mail.gmail.com> References: <426FC2A3.6000108@intertwingly.net> <68fba5c50504271003b63ab2d@mail.gmail.com> <426FF269.2030302@intertwingly.net> <68fba5c505042714312eeb0a58@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Date: Thu, 28 Apr 2005 00:11:39 +0100 X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [9de040e9b0e4621564d4e890e362cf4d] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27 Apr 2005, at 10:31 pm, Robert Sayre wrote: > My opinion is that ~10 WG members are currently clearly stating their > belief that summary/content are optional. You should make clear that most of those people supported a misleading Pace that didn't clearly state its side-effects beyond making feeds-where-no-title-is-available legal. Whether or not they support the general position that "summary/content are optional" is not for you to make. Graham From owner-atom-syntax@mail.imc.org Thu Apr 28 20:06:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10823 for ; Thu, 28 Apr 2005 20:06:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SNv4qJ034083; Thu, 28 Apr 2005 16:57:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3SNv4G7034080; Thu, 28 Apr 2005 16:57:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ns1.supercalendar.com (goodbyespam.com [209.216.35.52]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3SNv3JY034062 for ; Thu, 28 Apr 2005 16:57:03 -0700 (PDT) (envelope-from verify@goodbyespam.com) Received: from ns1.supercalendar.com (localhost.localdomain [127.0.0.1]) by ns1.supercalendar.com (8.12.8/8.12.8) with ESMTP id j3SNoPHi003518; Thu, 28 Apr 2005 16:57:03 -0700 Received: (from root@localhost) by ns1.supercalendar.com (8.12.8/8.12.8/Submit) id j3SLSBt3029493; Thu, 28 Apr 2005 14:28:11 -0700 To: ramin@wizen.com Subject: Re: On SHOULD, MUST, and semantics Received: (qmail 86727 invoked by uid 89); 27 Apr 2005 23:29:17 -0000 Received: from mx1.hrnoc.net (216.120.232.254) by mailbox2.hrnoc.net with QMTP; 27 Apr 2005 23:29:17 -0000 Received: (qmail 13477 invoked by uid 513); 27 Apr 2005 23:29:07 -0000 Received: from owner-atom-syntax@mail.imc.org by mx1.hrnoc.net by uid 503 with qmail-scanner-1.20st (clamuko: 0.70. spamassassin: 2.63. Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.178867 secs); 27 Apr 2005 23:29:07 -0000 X-Spam-Status: No, hits=0.0 required=15.0 X-Qmail-Scanner-Mail-From: owner-atom-syntax@mail.imc.org via mx1.hrnoc.net X-Qmail-Scanner: 1.20st (Clear:RC:0(208.184.76.39):SA:0(0.0/15.0):. Processed in 0.178867 secs) Received: from above.proper.com (208.184.76.39) by mx1.hrnoc.net with AES256-SHA encrypted SMTP; 27 Apr 2005 23:29:06 -0000 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RNCkT6001785; Wed, 27 Apr 2005 16:12:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3RNCkPd001782; Wed, 27 Apr 2005 16:12:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3RNChpd001774 for ; Wed, 27 Apr 2005 16:12:43 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3RNBfik015131; Thu, 28 Apr 2005 00:11:46 +0100 (BST) In-Reply-To: <68fba5c505042714312eeb0a58@mail.gmail.com> References: <426FC2A3.6000108@intertwingly.net> <68fba5c50504271003b63ab2d@mail.gmail.com> <426FF269.2030302@intertwingly.net> <68fba5c505042714312eeb0a58@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax From: Graham Date: Thu, 28 Apr 2005 00:11:39 +0100 X-Mailer: Apple Mail (2.622) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com List-Archive: List-Unsubscribe: List-ID: GOODBYESPAM_ID: [882d8ed43f6ea9aa11997cdd0c365cfc] Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 27 Apr 2005, at 10:31 pm, Robert Sayre wrote: > My opinion is that ~10 WG members are currently clearly stating their > belief that summary/content are optional. You should make clear that most of those people supported a misleading Pace that didn't clearly state its side-effects beyond making feeds-where-no-title-is-available legal. Whether or not they support the general position that "summary/content are optional" is not for you to make. Graham From owner-atom-syntax@mail.imc.org Fri Apr 29 00:16:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26962 for ; Fri, 29 Apr 2005 00:16:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3T49HHW070981; Thu, 28 Apr 2005 21:09:17 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3T49Hrv070980; Thu, 28 Apr 2005 21:09:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3T49GT6070969; Thu, 28 Apr 2005 21:09:16 -0700 (PDT) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j3T49FjO019529; Thu, 28 Apr 2005 22:09:15 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IFO00FNKWVE48@edgemail1.Central.Sun.COM>; Thu, 28 Apr 2005 22:09:15 -0600 (MDT) Received: from [192.168.1.17] ([216.113.201.83]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IFO002MMWVEUG@mail.sun.net>; Thu, 28 Apr 2005 22:09:14 -0600 (MDT) Date: Thu, 28 Apr 2005 21:10:10 -0700 From: Tim Bray Subject: Fwd: [rt.icann.org #2905] Last Call: 'The Atom Syndication Format' to Proposed Standard To: "'atom-syntax Syntax''" , Atom Protocol Message-id: <540a8c4dfb218405ff585025f0ec54b0@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Unsurprising, but good news I'd say: > From: "Michelle Cotton via RT" > Date: April 28, 2005 8:58:51 PM PDT > To: iesg@ietf.org > Cc: paul.hoffman@vpnc.org, rfsayre@boswijck.com, tbray@textuality.com > Subject: [rt.icann.org #2905] Last Call: 'The Atom Syndication Format' > to Proposed Standard > Reply-To: iana-drafts@icann.org > > IESG: > > The IANA has reviewed the following Internet-Draft which is in Last > Call: , and has the following > with regards to the publication of this document: > > Upon approval of this document the IANA will register the MIME media > type application/atom+xml. A Registry of Link Relations will be > created and will include the five initial values described in this > document. > > Thank you. > > Michelle Cotton > (on behalf of IANA) From owner-atom-syntax@mail.imc.org Fri Apr 29 09:37:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25673 for ; Fri, 29 Apr 2005 09:37:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TDSO8g001044; Fri, 29 Apr 2005 06:28:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3TDSOov001043; Fri, 29 Apr 2005 06:28:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TDSNAJ001037 for ; Fri, 29 Apr 2005 06:28:24 -0700 (PDT) (envelope-from brett.lindsley@labs.mot.com) Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j3TDSN1R017985 for ; Fri, 29 Apr 2005 06:28:23 -0700 (MST) Received: from labs.mot.com (udomsvc2.labs.mot.com [173.23.250.2]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id j3TDTvWF005903 for ; Fri, 29 Apr 2005 08:29:58 -0500 (CDT) Received: from udomsvc5.labs.mot.com (udomsvc5.labs.mot.com [173.23.250.5]) by labs.mot.com (MotLabs Smoke & Mirrors) with ESMTP id j3TDSMVp011785 for ; Fri, 29 Apr 2005 08:28:22 -0500 (CDT) Received: from labs.mot.com by ims1.labs.mot.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0IFP001L4MR89V@ims1.labs.mot.com> for atom-syntax@imc.org; Fri, 29 Apr 2005 08:28:20 -0500 (CDT) Date: Fri, 29 Apr 2005 08:28:20 -0500 From: Brett Lindsley Subject: Link Comments To: atom-syntax Message-id: <42723674.6060704@labs.mot.com> Organization: Mot Labs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> <426EF42C.5010505@intertwingly.net> <68fba5c505042619152ad7b5f6@mail.gmail.com> <426EFA35.8010103@intertwingly.net> <68fba5c505042707387c289d87@mail.gmail.com> <540e37320504272145dc0dd8c@mail.gmail.com> <68fba5c505042722395e8c66a@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Although it is not a show stopping problem, the link has some issues. This has been previously commented on by others. In particular, some of the attributes refer to the link (rel, title) whereas other attributes refer to what the link points to (length, type). There has also been some interest about multiple links to various representations of the same resource. The following situation is not unrealistic: Assume an entry describes a major event. Enclosures may have different representations of this event such as a SMIL slide show, an audio only mp3 or a video clip. These are all the same resource but has different representations. The end client can then download the one that is most appropriate for its rendering capabilities, storage capacity, etc. The link would look something like: To maintain compatibility with the current spec, one could limit the number of representations to one for particular types of rel's. Brett Lindsley, Motorola Labs. From owner-atom-syntax@mail.imc.org Fri Apr 29 12:17:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11191 for ; Fri, 29 Apr 2005 12:17:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TG9llY027725; Fri, 29 Apr 2005 09:09:47 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3TG9l6O027723; Fri, 29 Apr 2005 09:09:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3TG9jcF027713 for ; Fri, 29 Apr 2005 09:09:46 -0700 (PDT) (envelope-from pagaltzis@gmx.de) Received: (qmail invoked by alias); 29 Apr 2005 16:09:39 -0000 Received: from xdsl-213-196-242-27.netcologne.de (EHLO klangraum) [213.196.242.27] by mail.gmx.net (mp018) with SMTP; 29 Apr 2005 18:09:39 +0200 X-Authenticated: #163624 Date: Fri, 29 Apr 2005 18:12:43 +0200 From: "A. Pagaltzis" To: atom-syntax Subject: Re: PaceOptionalSummary Message-ID: <20050429161243.GA8428@klangraum> Mail-Followup-To: atom-syntax References: <357B1120-B698-11D9-874E-003065EA6144@geckotribe.com> <426EF42C.5010505@intertwingly.net> <68fba5c505042619152ad7b5f6@mail.gmail.com> <426EFA35.8010103@intertwingly.net> <68fba5c505042707387c289d87@mail.gmail.com> <540e37320504272145dc0dd8c@mail.gmail.com> <68fba5c505042722395e8c66a@mail.gmail.com> <540e3732050428044672abdc25@mail.gmail.com> <68fba5c505042806533cb12fa8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <68fba5c505042806533cb12fa8@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Please be aware that I’m not in any camp right now. I’m still vacillating, trying to understand the implications of this issue. I am leaning against MUST, but that’s not a done deal, and I’m not at all sure about MAY vs SHOULD. * Robert Sayre [2005-04-28 16:05]: > Your SHOULD allows competitors to turn off their feeds at any > time, and point to the spec as justification. Does it? Doesn’t SHOULD mean that it is perfectly within rights of the producer to drop the requested item on the floor? > Even worse, it could be "oh, some of their entries are buggy, > so we drop those." Now that, I could see (albeit not with that wording). By my reading of RFC2119, it is not entirely clear whether consumers would be required to process entries lacking both summary and content. Am I correct? In that case the problem lies in the asymmetry between producers and consumers of feeds; since the Atom spec adresses both, this could be clarified by adding that consumers MUST accept title-only entries, but of course, that would be implied if inclusion of a summary was OPTIONAL. So I guess the options are: 1. RECOMMEND providing a summary and REQUIRE processing entries whether one is provided or not 2. Make a summary OPTIONAL even in absence of content, and only informally mention the considerations feed providers should be aware of (possibly elsewhere). Is that right so far? Assuming my reasoning is sound and these are the choices, I’d still lean towards MAY, since verbiage is comparable in either case, but choice 2 simplifies the core spec. Regards, -- Aristotle From owner-atom-syntax@mail.imc.org Fri Apr 29 12:57:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15034 for ; Fri, 29 Apr 2005 12:57:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TGpRtM035226; Fri, 29 Apr 2005 09:51:27 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3TGpRDu035225; Fri, 29 Apr 2005 09:51:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TGpQgt035216 for ; Fri, 29 Apr 2005 09:51:27 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3TEtg8u001234 for ; Fri, 29 Apr 2005 10:55:42 -0400 Message-ID: <4272660C.7010603@intertwingly.net> Date: Fri, 29 Apr 2005 12:51:24 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: PaceTextShouldBeProvided Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit == Abstract == Encourage interoperability and accessibility by suggesting that key textual constructs be both present and non-empty. == Status == Open == Rationale == There are existance proofs of tools that either are less useful in the presence of entries without without a title, or ones without either a summary or inline textual content. In fact, at least one such tool discards such entries entirely. This fact, when viewed in isolation, would argue that such elements be mandatory. Unfortunately, there are also existence proofs of title-only feeds, and entries for which there are no titles. Reluctantly, this leads one to conclude that while they must be allowed, it would be irresponsible for the spec not to warn potential producers of such feeds that not providing a textual fallback may lead to interoperability issues. == Proposal == Make the following changes/addition to the draft-ietf-atompub-format-08 document. === section 3.1.1.1 === Change: If the value is "text", the content of the Text construct MUST NOT contain child elements. To: If the value is "text", the content of the Text construct MUST NOT contain child elements and SHOULD NOT be empty. === section 3.1.1.2 === Change: If the value of "type" is "html", the content of the Text construct MUST NOT contain child elements, and SHOULD be suitable for handling as HTML [HTML]. To: If the value of "type" is "html", the content of the Text construct MUST NOT contain child elements, SHOULD NOT be empty, and SHOULD be suitable for handling as HTML [HTML]. === section 3.1.1.3 === Change: The XHTML div MUST contain XHTML text and markup that could validly appear within an XHTML div element. To: The XHTML div SHOULD NOT be empty and MUST contain XHTML text and markup that could validly appear within an XHTML div element. === section 4.1.2 === Add: atom:entry elements SHOULD contain an atom:summary element if the atom:content in the form of atomInlineOtherContent. == Impacts == As these requirements are only SHOULDs, no feeds which are currently valid will become invalid. However, those that follow these suggestions will find that their feeds are useful to a wider audience than they would be otherwise. == Notes == In the event that PaceOptionalSummary is adopted, the words "is either not present or" would need to be added to the proposed addition to section 4.1.2. ---- CategoryProposals From owner-atom-syntax@mail.imc.org Fri Apr 29 19:32:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01545 for ; Fri, 29 Apr 2005 19:32:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TNLBXF002111; Fri, 29 Apr 2005 16:21:11 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3TNLBYH002110; Fri, 29 Apr 2005 16:21:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3TNL8M7002101; Fri, 29 Apr 2005 16:21:09 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4272660C.7010603@intertwingly.net> References: <4272660C.7010603@intertwingly.net> Date: Fri, 29 Apr 2005 16:21:06 -0700 To: Sam Ruby , Atom Syntax From: Paul Hoffman Subject: Re: PaceTextShouldBeProvided Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:51 PM -0400 4/29/05, Sam Ruby wrote: >Encourage interoperability and accessibility by suggesting that key >textual constructs be both present and non-empty. +1 >As these requirements are only SHOULDs, no feeds which are currently >valid will become invalid. However, those that follow these >suggestions will find that their feeds are useful to a wider >audience than they would be otherwise. Folks here know that I'm not a big fan of SHOULDs where a MUST or a MAY would be better. In this case, I can see that the changes suggested fit the classical IETF definition of SHOULD. We can't force you to put in real text because there really might be nothing for you to say without just making up gibberish, but you should really try hard to say something, even if it is repetitive. You don't know which locations the recipient is going to be looking in, as we have seen from some of the WG traffic in the past week. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Sat Apr 30 05:28:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23260 for ; Sat, 30 Apr 2005 05:28:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3U9JucX068855; Sat, 30 Apr 2005 02:19:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3U9Ju99068853; Sat, 30 Apr 2005 02:19:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3U9JspY068792 for ; Sat, 30 Apr 2005 02:19:55 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [10.0.2.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3U9Iu0E000935; Sat, 30 Apr 2005 10:19:02 +0100 (BST) In-Reply-To: <4272660C.7010603@intertwingly.net> References: <4272660C.7010603@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Atom Syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceTextShouldBeProvided Date: Sat, 30 Apr 2005 10:19:46 +0100 To: Sam Ruby X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 29 Apr 2005, at 5:51 pm, Sam Ruby wrote: > Encourage interoperability and accessibility by suggesting that key > textual constructs be both present and non-empty. +1 Graham From owner-atom-syntax@mail.imc.org Sat Apr 30 09:13:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04671 for ; Sat, 30 Apr 2005 09:13:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UD6CBV063542; Sat, 30 Apr 2005 06:06:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UD6Cbq063541; Sat, 30 Apr 2005 06:06:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18]) by above.proper.com (8.12.11/8.12.9) with SMTP id j3UD6AAk063414 for ; Sat, 30 Apr 2005 06:06:12 -0700 (PDT) (envelope-from bill@dehora.net) Received: (qmail 91316 messnum 5247801 invoked from network[83.70.217.193/unknown]); 30 Apr 2005 13:05:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (83.70.217.193) by mail02.svc.cra.dublin.eircom.net (qp 91316) with SMTP; 30 Apr 2005 13:05:59 -0000 Message-ID: <427382B5.8090900@dehora.net> Date: Sat, 30 Apr 2005 14:05:57 +0100 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceTextShouldBeProvided References: <4272660C.7010603@intertwingly.net> In-Reply-To: <4272660C.7010603@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > == Abstract == > > Encourage interoperability and accessibility by suggesting that key > textual constructs be both present and non-empty. > > == Status == > > Open > > == Rationale == > > There are existance proofs of tools that either are less useful in the > presence of entries without without a title, or ones without either a > summary or inline textual content. In fact, at least one such tool > discards such entries entirely. This fact, when viewed in isolation, > would argue that such elements be mandatory. > > Unfortunately, there are also existence proofs of title-only feeds, and > entries for which there are no titles. Reluctantly, this leads one to > conclude that while they must be allowed, it would be irresponsible for > the spec not to warn potential producers of such feeds that not > providing a textual fallback may lead to interoperability issues. The bias bothers me - why are the existence of title only feeds unfortunate, whereas tools that do not handle them gracefully are not? And, is this not the kind of spec text we've been traditionally kicking into the Fabled Implementors Guide? > === section 4.1.2 === > > Add: > > atom:entry elements SHOULD contain an atom:summary element if the > atom:content in the form of atomInlineOtherContent. -1 to this addition. > As these requirements are only SHOULDs, no feeds which are currently > valid will become invalid. However, those that follow these suggestions > will find that their feeds are useful to a wider audience than they > would be otherwise. As a rationale, usefulness to a wider audience is debatable. I'm concerned that this text is intended, or will be leveraged, to call out title-only feeds as bad practice. If this is accepted, I would ask the editors to take care that is not implied. cheers Bill From owner-atom-syntax@mail.imc.org Sat Apr 30 10:51:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11130 for ; Sat, 30 Apr 2005 10:51:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UEhAx7072555; Sat, 30 Apr 2005 07:43:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UEhAxl072554; Sat, 30 Apr 2005 07:43:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UEh8KQ072537 for ; Sat, 30 Apr 2005 07:43:09 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.50.71]) by smtp.cegetel.net (Postfix) with ESMTP id 573DD22C27A for ; Sat, 30 Apr 2005 16:43:02 +0200 (CEST) Message-ID: <42739975.20003@cegetel.net> Date: Sat, 30 Apr 2005 16:43:01 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: PaceXhtmlDivSuggestedOnly Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm aware that this Pace actually has two purposes: nuke the xhtml:div requirement and add distinction between inline and block content. If someone wants me to split it into two Paces, I'll do it, but I think these two purposes are related to each other and that's why I made a single Pace. http://intertwingly.net/wiki/pie/PaceXhtmlDivSuggestedOnly == Abstract == Make the XHTML div wrapper optional, as it causes more problems than it actually solves. == Status == Open == Rationale == The only purpose of the XHTML div wrapper is to have it carry the XHTML namespace declaration in case the feed producer doesn't want to use prefixed XML names (i.e. always use default namespaces). The required wrapper is also expected to prevent feeds using wrong namespaces. On the other hand, there has been many discussion about which attributes are allowed/forbidden on the wrapper and how they should be handled by Atom processors, without a clear and clean solution. Using a XHTML "div" element is also quite inappropriate in an atom:title element as a "div" is meant for block content whereas a title is merely expected to be used as inline content (e.g. by putting it inside an "h2" or "h3" XHTML element). This has no technical impact in the current spec as the div is not part of the content but it might disturb XHTML-friendly people. Finally, mandating a "foreign" (outside the Atom namespace) element but requiring it not being part of the content and not behaving as it would in its originating language (XHTML) is not a clean position: so is this element part of Atom or XHTML? == Proposal == Nuke the XHTML div requirement and adds distinction between inline and block content to help producers choose the best container for their content (div or span). This means making the following changes/addition to the draft-ietf-atompub-format-08 document. === section 3.1 === Change the {{{atomXHTMLTextConstruct}}} definition to this one: {{{ atomXHTMLTextConstruct = atomCommonAttributes, attribute type { "xhtml" }, (text | anyXHTML)* }}} And add the following paragraph: {{{ This specification further refines the Text construct depending on the kind of content that is expected. A Text constructs expecting inline content is further named Inline Text construct, whereas a Text construct expecting block content is named Block Text construct. }}} === section 3.1.1.2 === Replace the last paragraph with:{{{ If the value of "type" is "html", the content of the Text construct MUST NOT contain child elements, and SHOULD be suitable for handling as HTML [HTML]. Any markup within MUST be escaped; for example, "
" as "<br>". Atom Processors that display such content MAY use that markup to aid in its display. The content is subject to further constraints depending on its kind: o HTML markup within an Inline Text construct SHOULD be such that it could validly appear directly within an HTML element, after unescaping. o HTML markup within a Block Text construct SHOULD be such that it could validly appear directly within an HTML
element, after unescaping. }}} === section 3.1.1.3 === {{{ Example atom:title with XHTML content: ... Less: <xhtml:em> < </xhtml:em> ... If the value of "type" is "xhtml", the content of the Text construct MUST be XHTML [XHTML] text and markup. Atom Processors which display the content MAY use the markup to aid in displaying it. Escaped characters, such as "&" and ">", represent those characters, not markup. The content is subject to further constraints depending on its kind: o the content of an Inline Text construct MUST be XHTML text and markup that could validly appear within an XHTML span element. o the content of a Block Text construct MUST be XHTML text and markup that could validly appear within an XHTML div element. Examples of valid XHTML content: ... <span xmlns="http://www.w3.org/1999/xhtml"> This is an <b>XHTML</b> title </span>

Note that using span and div containers allows us to keep using default namespaces (namespaces not bound to any prefix).

The container element has been choosen to fit the kind of content it contains: span for inline content and div for block content.

... This is an XHTML paragraph. ... The following example assumes that the XHTML namespace has been bound to the "xh" prefix earlier in the document: ... This is XHTML content. ... }}} === section 4.1.3 The "atom:content" Element === Replace the {{{atomInlineXHTMLContent}}} definition with this one:{{{ atomInlineXHTMLContent = element atom:content { atomCommonAttributes, attribute type { "xhtml" }, anyXHTML } }}} === section 4.1.3.3 Processing Model === Replace third list item with this one:{{{ 3. If the value of "type" is "xhtml", the content of atom:content MUST be XHTML [XHTML] XHTML text and markup that could validly appear within an XHTML div element. Atom Processors that display the content MAY use the markup to aid in displaying it. Escaped characters, such as "&" and ">", represent those characters, not markup. }}} === section 4.2.4 The "atom:copyright" Element === In the first paragraph, replace "Text construct" with "Inline Text construct". === section 4.2.12 The "atom:subtitle" Element === In the first paragraph, replace "Text construct" with "Inline Text construct". === section 4.2.13 The "atom:summary" Element === In the first paragraph, replace "Text construct" with "Block Text construct". === section 4.2.14 The "atom:title" Element === In the first paragraph, replace "Text construct" with "Inline Text construct". == Impacts == Producers of Atom documents based on the IETF drafts and using XHTML content will have to either: * drop the XHTML div wrapper if they use prefixes for namespaces * change it to a "span" in atom:title and atom:copyright if they want to produce prefix-free Atom documents and check the XHTML content to be valid inside XHTML span or div elements * move to prefix-bound (non-default) namespaces and drop the XHTML div wrapper if they don't check the XHTML content == Notes == The "wrong namespace use" concern is answered in the second example, some might prefer making it clearer by putting the example description in its own spec paragraph and have the example only an illustration. ---- CategoryProposals From owner-atom-syntax@mail.imc.org Sat Apr 30 10:52:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11206 for ; Sat, 30 Apr 2005 10:52:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UEkuib073111; Sat, 30 Apr 2005 07:46:56 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UEkuSR073110; Sat, 30 Apr 2005 07:46:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UEktke073090 for ; Sat, 30 Apr 2005 07:46:55 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2299064wra for ; Sat, 30 Apr 2005 07:46:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=k1F4kDlTzqdeCD0uJPc7r9cBOj5XR3K1v34cL+J+KdMKrLGISOdw5hxMBiymgX3Qq9oFBq3ZWeDoCKVQdgrR//wodKrRWe1dXZAGsRp3Q9ssSGToE7uytqOtKubnoIcv6lALxAMIPRWGwuiqyFr1GTu/9r+T6rtUTMjhuzRy0O8= Received: by 10.54.26.2 with SMTP id 2mr2204643wrz; Sat, 30 Apr 2005 07:46:46 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Sat, 30 Apr 2005 07:46:46 -0700 (PDT) Message-ID: <68fba5c5050430074636f05f69@mail.gmail.com> Date: Sat, 30 Apr 2005 10:46:46 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: PaceTextShouldBeProvided Cc: Atom Syntax In-Reply-To: <4272660C.7010603@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4272660C.7010603@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3UEktke073102 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/29/05, Sam Ruby wrote: > > == Abstract == > > Encourage interoperability and accessibility by suggesting that key > textual constructs be both present and non-empty. > I'd prefer that a bit more of the rationale made it into the text. Explain why we are saying SHOULD. > > === section 4.1.2 === > > Add: > > atom:entry elements SHOULD contain an atom:summary element if the > atom:content in the form of atomInlineOtherContent. This section needs to be reworked. We can't make normative reference to the RNG. > == Notes == > > In the event that PaceOptionalSummary is adopted, the words "is either > not present or" would need to be added to the proposed addition to > section 4.1.2. -1 to this. If PaceOptionalSummary is adopted, the summary will be a MAY, not a SHOULD. Please put your proposals in the section marked "Proposal". Robert Sayre From owner-atom-syntax@mail.imc.org Sat Apr 30 11:23:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13268 for ; Sat, 30 Apr 2005 11:23:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UFFEm4077450; Sat, 30 Apr 2005 08:15:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UFFEeV077449; Sat, 30 Apr 2005 08:15:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UFFDF7077435 for ; Sat, 30 Apr 2005 08:15:13 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3UDJXrH008804; Sat, 30 Apr 2005 09:19:33 -0400 Message-ID: <4273A0FE.10905@intertwingly.net> Date: Sat, 30 Apr 2005 11:15:10 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom Syntax Subject: Re: PaceTextShouldBeProvided References: <4272660C.7010603@intertwingly.net> <68fba5c5050430074636f05f69@mail.gmail.com> In-Reply-To: <68fba5c5050430074636f05f69@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > On 4/29/05, Sam Ruby wrote: > >>== Abstract == >> >>Encourage interoperability and accessibility by suggesting that key >>textual constructs be both present and non-empty. > > I'd prefer that a bit more of the rationale made it into the text. > Explain why we are saying SHOULD. Suggestions? Is this something that the editor can handle? >>=== section 4.1.2 === >> >>Add: >> >> atom:entry elements SHOULD contain an atom:summary element if the >>atom:content in the form of atomInlineOtherContent. > > > This section needs to be reworked. We can't make normative reference to the RNG. Suggestions? Is this something that the editor can handle? >>== Notes == >> >>In the event that PaceOptionalSummary is adopted, the words "is either >>not present or" would need to be added to the proposed addition to >>section 4.1.2. > > -1 to this. > > If PaceOptionalSummary is adopted, the summary will be a MAY, not a > SHOULD. Please put your proposals in the section marked "Proposal". At the moment, the proposal is based on the existing draft-ietf-atompub-format-08. PaceOptionalSummary does not introduce a MAY, it removes a crucial MUST -- one that, if removed, would exasperate the problem that PaceTextShouldBeProvided is intended to address. - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Apr 30 11:32:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13628 for ; Sat, 30 Apr 2005 11:32:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UFNE87078471; Sat, 30 Apr 2005 08:23:14 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UFNEKP078470; Sat, 30 Apr 2005 08:23:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UFND9j078455 for ; Sat, 30 Apr 2005 08:23:14 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2308182wra for ; Sat, 30 Apr 2005 08:23:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kngRiCMcjLwzKQ5PjWbOd0CGAa2SuYJO4yJqBfVtmNNCa9Rkpb8XBOpwCr+cA0+p7PkScDaY0jkryZZpal6I1NmpdHkFrec+In+HVdvQCEb+Od6EQV2j8tnNi0pWuPGGLYlvZBV333egv2S2o4qjl6QxHqt9n4EDTG9uINCEy30= Received: by 10.54.121.19 with SMTP id t19mr1867520wrc; Sat, 30 Apr 2005 08:23:08 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Sat, 30 Apr 2005 08:23:08 -0700 (PDT) Message-ID: <68fba5c5050430082336dbaea1@mail.gmail.com> Date: Sat, 30 Apr 2005 11:23:08 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Sam Ruby Subject: Re: PaceTextShouldBeProvided Cc: Atom Syntax In-Reply-To: <4273A0FE.10905@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4272660C.7010603@intertwingly.net> <68fba5c5050430074636f05f69@mail.gmail.com> <4273A0FE.10905@intertwingly.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3UFNE9j078464 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Suggestions? Is this something that the editor can handle? Maybe Mark can. This editor doesn't understand the rationale. > > > > This section needs to be reworked. We can't make normative reference to the RNG. > > Suggestions? Is this something that the editor can handle? Paces should provide camera-ready text. > > PaceOptionalSummary does not introduce a MAY, it removes a crucial MUST Obviously, the WG doesn't find that MUST particularly crucial. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Apr 30 12:30:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16107 for ; Sat, 30 Apr 2005 12:30:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UGKw3F086324; Sat, 30 Apr 2005 09:20:58 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UGKwgX086323; Sat, 30 Apr 2005 09:20:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UGKvlg086307 for ; Sat, 30 Apr 2005 09:20:58 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3UGKbiR011879; Sat, 30 Apr 2005 17:20:38 +0100 (BST) In-Reply-To: <68fba5c5050430082336dbaea1@mail.gmail.com> References: <4272660C.7010603@intertwingly.net> <68fba5c5050430074636f05f69@mail.gmail.com> <4273A0FE.10905@intertwingly.net> <68fba5c5050430082336dbaea1@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceTextShouldBeProvided Date: Sat, 30 Apr 2005 17:20:36 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Obviously, the WG doesn't find that MUST particularly crucial. Robert, will you stop banging your drum about this and let the WG get a word in edgeways? If your position has such unanimous support it will survive without you. Thank you. Graham From owner-atom-syntax@mail.imc.org Sat Apr 30 12:30:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16109 for ; Sat, 30 Apr 2005 12:30:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UGJfvw086155; Sat, 30 Apr 2005 09:19:41 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UGJfxd086154; Sat, 30 Apr 2005 09:19:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UGJdRD086136 for ; Sat, 30 Apr 2005 09:19:40 -0700 (PDT) (envelope-from dtcd@mac.com) Received: from [161.73.58.69] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j3UGHb08011351; Sat, 30 Apr 2005 17:17:43 +0100 (BST) In-Reply-To: <42739975.20003@cegetel.net> References: <42739975.20003@cegetel.net> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: atom-syntax Content-Transfer-Encoding: 7bit From: Graham Subject: Re: PaceXhtmlDivSuggestedOnly Date: Sat, 30 Apr 2005 17:17:36 +0100 To: Thomas Broyer X-Mailer: Apple Mail (2.728) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 30 Apr 2005, at 3:43 pm, Thomas Broyer wrote: > Using a XHTML "div" element is also quite inappropriate in an > atom:title element as a "div" is meant for block content whereas a > title is merely expected to be used as inline content (e.g. by > putting it inside an "h2" or "h3" XHTML element). The div is not part of the content, and inline content can safely appear within a div. -1. Next. Graham From owner-atom-syntax@mail.imc.org Sat Apr 30 12:43:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16846 for ; Sat, 30 Apr 2005 12:43:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UGa7qX088220; Sat, 30 Apr 2005 09:36:07 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UGa7WX088219; Sat, 30 Apr 2005 09:36:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UGa544088194 for ; Sat, 30 Apr 2005 09:36:06 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2325936wra for ; Sat, 30 Apr 2005 09:36:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kMXbo7KQK418X7OAGZfzFuXXHFU8B3cWs/oxOZLkNcuL83VQuEJsu+X2Zz6dMGyhI5SEkThiZF6ieTitRtTkib5Iw1fmboTw6ScprMDY9g9ke46kHb5+yWMTyfQP7IpaMOI8wC2wSEK3Y8sJqb4WBNid3YKVYOShEvYcUSHWz50= Received: by 10.54.121.5 with SMTP id t5mr1636050wrc; Sat, 30 Apr 2005 09:36:00 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Sat, 30 Apr 2005 09:36:00 -0700 (PDT) Message-ID: <68fba5c505043009363aec2ef1@mail.gmail.com> Date: Sat, 30 Apr 2005 12:36:00 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Tim Bray , Paul Hoffman Subject: Re: PaceTextShouldBeProvided Cc: atom-syntax , Graham In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <4272660C.7010603@intertwingly.net> <68fba5c5050430074636f05f69@mail.gmail.com> <4273A0FE.10905@intertwingly.net> <68fba5c5050430082336dbaea1@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3UGa644088207 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/30/05, Graham wrote: > > Obviously, the WG doesn't find that MUST particularly crucial. > > Robert, will you stop banging your drum about this and let the WG get > a word in edgeways? If your position has such unanimous support it > will survive without you. So, I have to be quiet. Is that what you're saying? Let me suggest you take your own advice. I wrote six sentences, after a day of no one paying attention to this pointless, intentionally obfuscated, and otherwise badly written proposal. Robert Sayre On 4/28/05, Tim Bray wrote: > > And of course we're going to have to fish some sort of > consensus out of this horrid summary-required mess. -Tim Bill responded > I can't agree with that observation. Although there are a few strenuous > objections against title only feeds, on the balance consensus is for > them. Is there something you're seeing that should make us think the > current consensus level is inadequate? From owner-atom-syntax@mail.imc.org Sat Apr 30 14:17:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22261 for ; Sat, 30 Apr 2005 14:17:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UI3Wog099001; Sat, 30 Apr 2005 11:03:32 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UI3WNC099000; Sat, 30 Apr 2005 11:03:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UI3Uoa098991 for ; Sat, 30 Apr 2005 11:03:30 -0700 (PDT) (envelope-from t.broyer@cegetel.net) Received: from [127.0.0.1] (unknown [84.5.50.71]) by smtp.cegetel.net (Postfix) with ESMTP id 3120022C216; Sat, 30 Apr 2005 20:03:24 +0200 (CEST) Message-ID: <4273C870.5000700@cegetel.net> Date: Sat, 30 Apr 2005 20:03:28 +0200 From: Thomas Broyer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: Graham Cc: atom-syntax Subject: Re: PaceXhtmlDivSuggestedOnly References: <42739975.20003@cegetel.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > On 30 Apr 2005, at 3:43 pm, Thomas Broyer wrote: > >> Using a XHTML "div" element is also quite inappropriate in an >> atom:title element as a "div" is meant for block content whereas a >> title is merely expected to be used as inline content (e.g. by >> putting it inside an "h2" or "h3" XHTML element). > > > The div is not part of the content, and inline content can safely > appear within a div. I'm OK with that but I'm still bothered by putting my titles in a block-level element: because the div is still part of XHTML (even if not part of the content here), which defines it as a block-level container! Are you considering the following title OK?

Hey this is an entry title!

Look what the Atom spec allows us to do with it!

 If not (which I suppose), then the spec should at least be changed to introduce inline vs. block content. And the same distinction should be done for escaped HTML content to forbid (well, actually not, I know, because we use a SHOULD and not a MUST) titles like this one: Hey this is an entry title!

Look what the Atom spec allows us to do with it!

]]> > -1. > > Next. I'm not sure it's so easy. There's another problem with the actual spec: it allows any attribute on the XHTML div container without defining how they have to be handled. Should they be discarded along with the div? Should they be somehow "inherited" by the content? If the spec is changed to forbid any attribute (other than the XHTML namespace declaration), then the XHTML div is not really an XHTML div, it becomes (and actually it already is, as it is not part of the content) a dummy container belonging to the XHTML namespace, whichever its name (though it's better if it looks like an existing XHTML element). I'm sorry but these kind of "hacks" have nothing to do within a standard (IETF or else), especially if they have no mean other than just being hacks and if there are clean solutions: Atom is XML using XML namespaces, it's enough for usefulness without the need to introduce such a dummy container; and people willing to use default namespaces only (prefix-free XML names) can still achieve that by introducing meaningless "span" or "div" containers, with the difference they will be part of the content. -- Thomas Broyer From owner-atom-syntax@mail.imc.org Sat Apr 30 15:15:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26323 for ; Sat, 30 Apr 2005 15:15:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UJ3pFG006240; Sat, 30 Apr 2005 12:03:51 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UJ3pB0006239; Sat, 30 Apr 2005 12:03:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UJ3o77006229 for ; Sat, 30 Apr 2005 12:03:50 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by rproxy.gmail.com with SMTP id z35so366285rne for ; Sat, 30 Apr 2005 12:03:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=pUE+vCFA40UH+8q600IXVMcpfN6gQHsJ/6onZfhW6LXoZ0z/uCXBMlG5yvWklyzscBuQRkgQqsdKGIpBqeA8kCjBAnUEE5lqYYlsScUHNQrlnezpAjgsYizPuPR1ihhXKZ6HuP5NzcroTFRYZiQH6pwoRAR0O29+L9CfMwqAJNg= Received: by 10.38.104.52 with SMTP id b52mr4737440rnc; Sat, 30 Apr 2005 12:03:50 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Sat, 30 Apr 2005 12:03:50 -0700 (PDT) Message-ID: <68fba5c5050430120381bba2a@mail.gmail.com> Date: Sat, 30 Apr 2005 15:03:50 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: PaceOptionalFeedLink Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3UJ3p77006233 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit == Abstract == Remove the requirement for a feed-level link element. == Status == Open == Rationale == The requirement makes people jump through hoops for little gain, since there is a strong incentive to provide the link if you have something. Unlike entries, feeds are almost always dereferenced from a URI. == Proposal == In section 4.1.1, strike the line that reads "atom:feed elements MUST contain at least one atom:link element with a relation of "alternate"." and replace it with "atom:feed elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same combination of type and hreflang attribute values." == Impacts == == Notes == ---- CategoryProposals From owner-atom-syntax@mail.imc.org Sat Apr 30 16:01:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29553 for ; Sat, 30 Apr 2005 16:01:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UJrjOI013030; Sat, 30 Apr 2005 12:53:45 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UJrjjc013029; Sat, 30 Apr 2005 12:53:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UJritZ013011 for ; Sat, 30 Apr 2005 12:53:44 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (sccrmhc13) with SMTP id <20050430195338016002ikhke>; Sat, 30 Apr 2005 19:53:38 +0000 Date: Sat, 30 Apr 2005 13:53:36 -0600 Subject: Re: PaceXhtmlDivSuggestedOnly Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <4273C870.5000700@cegetel.net> Message-Id: <8A906C28-B9B1-11D9-A2C6-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Saturday, April 30, 2005, at 12:03 PM, Thomas Broyer wrote: > Graham wrote: >> The div is not part of the content, and inline content can safely >> appear within a div. > > I'm OK with that but I'm still bothered by putting my titles in a > block-level element: because the div is still part of XHTML (even if > not part of the content here), which defines it as a block-level > container! PaceXmlContentWrapper would enable the use of an inline element in Atom elements that aren't supposed to have block content. And it would enable people who declare the namespace elsewhere to omit the container element. And it would keep the status of the top level element in the content, if there is one, unambiguous. > Are you considering the following title OK? > > >
>

Hey this is an entry title!

>

Look what the Atom spec allows us to do with it!

>
> > > If not (which I suppose), then the spec should at least be changed to > introduce inline vs. block content. > > And the same distinction should be done for escaped HTML content to > forbid (well, actually not, I know, because we use a SHOULD and not a > MUST) titles like this one: > >

Hey this is an entry title!

>

Look what the Atom spec allows us to do with it!

> ]]> I'd support forbidding block markup in titles and other such places where it's not appropriate. > I'm not sure it's so easy. There's another problem with the actual > spec: it allows any attribute on the XHTML div container without > defining how they have to be handled. > Should they be discarded along with the div? Should they be somehow > "inherited" by the content? I'd support forbidding any attributes other than (a) namespace declaration(s) on container elements...in fact, I'm going to add that to PaceXmlContentWrapper. > If the spec is changed to forbid any attribute (other than the XHTML > namespace declaration), then the XHTML div is not really an XHTML div, > it becomes (and actually it already is, as it is not part of the > content) a dummy container belonging to the XHTML namespace, whichever > its name (though it's better if it looks like an existing XHTML > element). I disagree with this characterization. We may have profiled the XHTML div element for this particular use, but that doesn't stop it from being an XHTML div. > I'm sorry but these kind of "hacks" have nothing to do within a > standard (IETF or else), especially if they have no mean other than > just being hacks and if there are clean solutions: Atom is XML using > XML namespaces, it's enough for usefulness without the need to > introduce such a dummy container; and people willing to use default > namespaces only (prefix-free XML names) can still achieve that by > introducing meaningless "span" or "div" containers, with the > difference they will be part of the content. If the author adds a div or span, that's fine. But if the software ads it, it's altering the author's content, and should have a way to so indicate so that the change can be undone. From owner-atom-syntax@mail.imc.org Sat Apr 30 16:11:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00015 for ; Sat, 30 Apr 2005 16:11:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UK24dC013990; Sat, 30 Apr 2005 13:02:04 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UK24uX013989; Sat, 30 Apr 2005 13:02:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UK24Gp013982 for ; Sat, 30 Apr 2005 13:02:04 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by rproxy.gmail.com with SMTP id z35so384363rne for ; Sat, 30 Apr 2005 13:02:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=OftqeBfZA+f/JfTpAC5i14BIDV+80sAN76ukouAZy/mlEhFySoWI58mVfQmsOCEBVxz7MMtCLgPW45KMcK9OcvVIP8Mmqh6ubuMyYZ8pl86A6wVt3mQdsViDkzDyGiJacZPg0b0EybQ7dhISJWaE3Tkett8HXW3Dp88GHZD3xVE= Received: by 10.38.65.1 with SMTP id n1mr4714428rna; Sat, 30 Apr 2005 13:02:03 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Sat, 30 Apr 2005 13:02:03 -0700 (PDT) Message-ID: <68fba5c505043013021b5ae924@mail.gmail.com> Date: Sat, 30 Apr 2005 16:02:03 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Atom Syntax Subject: PaceExplainDuplicateIds Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3UK24Gp013983 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Feel free to suggest alternate mealy-mouthed wording. :) == Abstract == Weakens the constraint on duplicate entry ids in feeds to a SHOULD. == Status == Open == Rationale == The proposed compromise to allow duplicate IDs in feeds, on the condition that a source element is present, doesn't address the problem of quick scripts that probably won't group duplicate IDs. This means that compliant processors will still differ from one-off hacks. Rather than legislate the constraint, we should explain the situation, and give the validator a SHOULD-level requirement so a warning can be triggered. == Proposal == Remove the bullet point that reads {{{ atom:feed elements MUST NOT contain atom:entry elements with identical atom:id values. }}} Add a paragraph after the list that reads {{{ Atom Processors use the atom:id element found in Atom entries to identify distinct entries. It is RECOMMENDED that each entry in an Atom Feed Document have a distinct atom:id value. }}} == Impacts == == Notes == ---- CategoryProposals From owner-atom-syntax@mail.imc.org Sat Apr 30 16:29:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00923 for ; Sat, 30 Apr 2005 16:29:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UKHbmo015940; Sat, 30 Apr 2005 13:17:37 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UKHbQ2015939; Sat, 30 Apr 2005 13:17:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UKHbI3015919 for ; Sat, 30 Apr 2005 13:17:37 -0700 (PDT) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-67-169-247-97.hsd1.ut.comcast.net[67.169.247.97]) by comcast.net (rwcrmhc14) with SMTP id <2005043020172801400fqk4ce>; Sat, 30 Apr 2005 20:17:29 +0000 Date: Sat, 30 Apr 2005 14:17:27 -0600 Subject: Re: PaceExplainDuplicateIds Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <68fba5c505043013021b5ae924@mail.gmail.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Saturday, April 30, 2005, at 02:02 PM, Robert Sayre wrote: > The proposed compromise to allow duplicate IDs in feeds, on the > condition that a source element is present, doesn't address the > problem of quick scripts that probably won't group duplicate IDs. I don't understand the last part of this sentence--could you explain? Thanks. From owner-atom-syntax@mail.imc.org Sat Apr 30 16:46:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02016 for ; Sat, 30 Apr 2005 16:46:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UKY9he018137; Sat, 30 Apr 2005 13:34:09 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UKY9ap018136; Sat, 30 Apr 2005 13:34:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UKY8qR018128 for ; Sat, 30 Apr 2005 13:34:08 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by rproxy.gmail.com with SMTP id z35so393976rne for ; Sat, 30 Apr 2005 13:34:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aOYJm5wr7clQtBP3XN9KoGMhqVsw3YeY2Js+z+6PYCrVcpsLtDCQ/F7t0gDihn5ZS8pAFObgZAjcWcMw4DWRhhLW3c+4ciLQLpAB1stEtLGFftNnIXAsTr8XdjcPHKxSF6cyLA00gkDMD3Cd7mPe/s1BAH2ZsdvdWnd/Gs44DmI= Received: by 10.38.14.1 with SMTP id 1mr4858764rnn; Sat, 30 Apr 2005 13:34:07 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Sat, 30 Apr 2005 13:34:06 -0700 (PDT) Message-ID: <68fba5c5050430133435a4e501@mail.gmail.com> Date: Sat, 30 Apr 2005 16:34:06 -0400 From: Robert Sayre Reply-To: Robert Sayre To: Antone Roundy Subject: Re: PaceExplainDuplicateIds Cc: atom-syntax@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505043013021b5ae924@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j3UKY8qR018131 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/30/05, Antone Roundy wrote: > > On Saturday, April 30, 2005, at 02:02 PM, Robert Sayre wrote: > > > The proposed compromise to allow duplicate IDs in feeds, on the > > condition that a source element is present, doesn't address the > > problem of quick scripts that probably won't group duplicate IDs. > > I don't understand the last part of this sentence--could you explain? Sure. Take a look at the discussion here: http://www.intertwingly.net/blog/2005/04/09/Clone-Wars Say someone writes a quick PHP script that doesn't keep any state and loops through the entries to display them on a web page. They'll have different results than a well-written desktop aggregator. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Apr 30 16:58:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02469 for ; Sat, 30 Apr 2005 16:58:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UKpAxL020721; Sat, 30 Apr 2005 13:51:10 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j3UKpAph020719; Sat, 30 Apr 2005 13:51:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j3UKpAP4020702 for ; Sat, 30 Apr 2005 13:51:10 -0700 (PDT) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 1B853C7 for ; Sat, 30 Apr 2005 13:51:05 -0700 (PDT) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j3UKowng005280 for ; Sat, 30 Apr 2005 13:51:04 -0700 (PDT) Date: Sat, 30 Apr 2005 13:51:18 -0700 From: Walter Underwood To: Atom Syntax Subject: Re: PaceOptionalFeedLink Message-ID: <9B1B53CD71B410E20CEFE3B3@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <68fba5c5050430120381bba2a@mail.gmail.com> References: <68fba5c5050430120381bba2a@mail.gmail.com> X-Mailer: Mulberry/4.0.0b1 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On April 30, 2005 3:03:50 PM -0400 Robert Sayre wrote: > > "atom:feed elements MUST NOT contain more than one atom:link element > with a rel attribute value of "alternate" that has the same > combination of type and hreflang attribute values." That actually specifies something different, the duplication, without saying whether atom:link is recommended. I recommend adding this text: "An atom:feed element SHOULD/MAY contain one such atom:link element." I'll let other people contribute on whether it is SHOULD or MAY. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Sat Apr 30 22:49:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19091 for ; Sat, 30 Apr 2005 22:49:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j411ldU0055911; Sat, 30 Apr 2005 18:47:39 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j411ldjS055910; Sat, 30 Apr 2005 18:47:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j411lc9o055901 for ; Sat, 30 Apr 2005 18:47:38 -0700 (PDT) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.102] (cpe-066-057-027-065.nc.res.rr.com [66.57.27.65]) (authenticated bits=0) by vanadium.sabren.com (8.12.11/8.12.11) with ESMTP id j3UNpv0i006044; Sat, 30 Apr 2005 19:52:00 -0400 Message-ID: <42743534.6020100@intertwingly.net> Date: Sat, 30 Apr 2005 21:47:32 -0400 From: Sam Ruby User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: atom-syntax@imc.org Subject: Re: PaceExplainDuplicateIds References: <68fba5c505043013021b5ae924@mail.gmail.com> <68fba5c5050430133435a4e501@mail.gmail.com> In-Reply-To: <68fba5c5050430133435a4e501@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > On 4/30/05, Antone Roundy wrote: > >>On Saturday, April 30, 2005, at 02:02 PM, Robert Sayre wrote: >> >>>The proposed compromise to allow duplicate IDs in feeds, on the >>>condition that a source element is present, doesn't address the >>>problem of quick scripts that probably won't group duplicate IDs. >> >>I don't understand the last part of this sentence--could you explain? > > Sure. Take a look at the discussion here: > http://www.intertwingly.net/blog/2005/04/09/Clone-Wars > > Say someone writes a quick PHP script that doesn't keep any state and > loops through the entries to display them on a web page. They'll have > different results than a well-written desktop aggregator. There can be no expectation about interoperability of invalid feeds. In the feed mentioned there, I presume that the "spid" part of the URI was meant to be substituted with some sort of product id. The ids encoded inside the links clearly would do. Heck, the links themselves are better "globally unique identifiers" than the ones provided as the guids. One of the clearest requirements that aggregator authors have provided to Atom is the wisdom of requiring unique IDs on entries. There may be consensus that unique by source is sufficient. - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Apr 30 23:25:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20973 for ; Sat, 30 Apr 2005 23:25:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j413Gkla069672; Sat, 30 Apr 2005 20:16:46 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j413GkDL069671; Sat, 30 Apr 2005 20:16:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j413GiAO069658 for ; Sat, 30 Apr 2005 20:16:45 -0700 (PDT) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j413Fgqp029684; Sat, 30 Apr 2005 23:15:42 -0400 (EDT) Received: from boblaptop (cpe-68-174-167-137.nyc.res.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id DBH19762; Sat, 30 Apr 2005 23:15:41 -0400 (EDT) Message-Id: <200505010315.DBH19762@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Robert Sayre'" , "'Atom Syntax'" Subject: RE: PaceExplainDuplicateIds Date: Sat, 30 Apr 2005 23:15:40 -0400 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVNwoT7tL4mTZiERHmmEMm6gP+4fgAOM+wQ In-Reply-To: <68fba5c505043013021b5ae924@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > compliant processors will still differ from one-off hacks. Why in the world are we letting "one-off hacks" influence the design of Atom? That strikes me as rather unwise. We aren't here to make life easy for script-kiddies. We're here to design a format that allows us to build useful applications for the people who rely on our systems. The fact that it might be a little difficult for some children or hackers to build decent code is not something that should enter into our considerations. The spec should STRONGLY state that each entry must have a unique atom id. The point of the "require source" language is not to remove the requirement for uniqueness but rather to provide a more useful way of doing cross-feed determination of uniqueness. bob wyman From owner-atom-syntax@mail.imc.org Sat Apr 30 23:39:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21532 for ; Sat, 30 Apr 2005 23:39:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j413RGvB071432; Sat, 30 Apr 2005 20:27:16 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j413RGFN071431; Sat, 30 Apr 2005 20:27:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j413RFY1071414 for ; Sat, 30 Apr 2005 20:27:15 -0700 (PDT) (envelope-from sayrer@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so2413911wra for ; Sat, 30 Apr 2005 20:27:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TPWWqCpKnkIRto/35EHXQZn0AqM6iKl/FWuSJ5aUv/Bt+VHOBR/M9lVLuhy6JheZN1HfcxQPBB3s0tN5iSU9dTsWPNzH8ep2cTnQiZqneDCNUruJjbU56Qy2OPpaVFSJj5wM+fRfJlsWx1CntEokkFoTPhEZf56wAqkuOWRXhi8= Received: by 10.54.106.1 with SMTP id e1mr216824wrc; Sat, 30 Apr 2005 20:21:46 -0700 (PDT) Received: by 10.54.72.7 with HTTP; Sat, 30 Apr 2005 20:21:45 -0700 (PDT) Message-ID: <68fba5c50504302021b8405a8@mail.gmail.com> Date: Sat, 30 Apr 2005 23:21:45 -0400 From: Robert Sayre Reply-To: Robert Sayre To: bob@wyman.us Subject: Re: PaceExplainDuplicateIds Cc: Atom Syntax In-Reply-To: <200505010315.DBH19762@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <68fba5c505043013021b5ae924@mail.gmail.com> <200505010315.DBH19762@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j413RFY1071426 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 4/30/05, Bob Wyman wrote: > The spec should STRONGLY state that each entry must have a unique > atom id. The point of the "require source" language is not to remove the > requirement for uniqueness but rather to provide a more useful way of doing > cross-feed determination of uniqueness. OK, that's fine with me. There is no "required source" language, though. Someone should write a Pace. This WG has, shall we say, more active management than most. I'm afraid I can't just write down what I think you mean. Robert Sayre From owner-atom-syntax@mail.imc.org Tue May 3 04:37:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14022 for ; Tue, 3 May 2005 04:37:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j438ROEc006985; Tue, 3 May 2005 01:27:24 -0700 (PDT) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j438ROPi006984; Tue, 3 May 2005 01:27:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j438RLAZ006940 for ; Tue, 3 May 2005 01:27:22 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j438RCm11924; Tue, 3 May 2005 17:27:12 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id 39a03246_bbad_11d9_9799_0030482533a1_18947; Tue, 03 May 2005 17:27:45 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO004DF5; 3 May 05 17:29:23 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 3 May 05 17:29:01 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.52) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG004DF2; 3 May 05 17:29:00 +0900 Message-Id: <6.0.0.20.2.20050429121745.06a3a060@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 29 Apr 2005 18:17:11 +0900 To: Alexey Melnikov , Mark Nottingham , Robert Sayre From: Martin Duerst Subject: Re: Last Call: 'The Atom Syndication Format' to Proposed Standard Cc: iesg@ietf.org, atom-syntax@imc.org In-Reply-To: <42712C6D.4030905@isode.com> References: <42712C6D.4030905@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit At 03:33 05/04/29, Alexey Melnikov wrote: >>The file can be obtained via >>http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt > >3.1.1.1 Text > > If the value is "text", the content of the Text construct MUST NOT > > contain child elements. Such text is intended to be presented to > > humans in a readable fashion. Thus, Atom Processors MAY collapse > > white-space (including line-breaks), > >Ok, maybe it is just me, but what does it mean to "collapse white-space"? Does this mean to replace FWS (in RFC 2822 sense) with a single space? Making this more precise is definitely desirable. But there is also an i18n issue: This works fine for languages that use spaces between words. It doesn't work for languages that don't have spaces between words (Chinese, Japanese, Thai,...). If Text elements are only used for short things such as names or titles, that's not a big issue, the text in question can just be put on a single line. However, when the texts in question are long, it's a serious issue, and should be fixed. > > and display the text using > > typographic techniques such as justification and proportional fonts. > > > >4.1.3.3 Processing Model >... > > 2. If the value of "type" is "html", the content of atom:content > > MUST NOT contain child elements, and SHOULD be suitable for > > handling as HTML [HTML]. The HTML markup must be escaped; for > >Should the "must" be changed to MUST here? Yes, please! > >6.3 Software Processing of Foreign Markup > > >... > > When unknown foreign markup is encountered in a Text Contruct or > > atom:content element, software SHOULD ignore the markup and process > > any text content of foreign elements as though the surrounding markup > > were not present. > >I reread this paragraph few times and I am still not quite sure what the paragraph is trying to say. Is it trying to say "if the content of a foreign element looks like XML with unrecognized schema - just strip the markup and process the text"? Reading this, I got confused because we have both "Text Construct" and "Text" as subtitles. I suggest to change the subtitle "Text" to something like "Text Construct with type='text'" or so. Also, starting a section with just an example looks weird. Please add an introductory sentence. Same of course for the parallel subsections. Regards, Martin.