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